The current python-test job creates and compresses python related
artifacts for use by future jobs. The artifacts are currently named
`mesa-python-test` which is somewhat misleading because they are not
needed for testing python scripts or libraries.
Rename the artifacts generated by the python-test job to be more
descriptive of their purpose.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
Out of 5 run during busy hours, all the jobs that once took 5+ min are:
build-for-tests / debian-arm64-asan 6 min
build-only / debian-s390x 6 min
build-only / debian-android 7 min
build-only / debian-clang 8 min
build-for-tests / debian-arm32-asan 8 min
build-only / debian-vulkan 11 min
build-for-tests / debian-testing 12 min
build-only / debian-testing-msan 12 min
build-only / debian-clang-release 13 min
build-only / alpine-build-testing 14 min
build-for-tests / debian-testing-asan 21 min
The jobs at 10+ min are considered to take long enough that they might
risk crossing the 15 min mark, so let's keep these ones at 30 min and
lower the timeout for everyone else to 15 min.
It's worth pointing out that debian-testing-asan is a build-for-tests
job and as such it blocks build-only jobs from running until it's
finished, which can be a problem for a job that has been seen taking 20+
minutes. We should do something about that, but that's not the topic of
this MR.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31846>
GitLab doesn't (yet) support `timeout:` being a variable, so let's put
the real `timeout:` at the max timeout we want, and internally use
another timeout (using coreutils' `timeout`) that we _can_ set using
a variable.
With that, we can set a 1h timeout on nightly LTO builds while keeping
our tighter 30min timeout the rest of the time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31846>
In function 'r600_init_resource_fields',
inlined from 'r600_buffer_create' at ../src/gallium/drivers/r600/r600_buffer_common.c:561:2:
../src/gallium/drivers/r600/r600_buffer_common.c:121:48: error: array subscript 'struct r600_texture[0]' is partly outside array bounds of 'unsigned char[256]' [-Werror=array-bounds=]
121 | if ((res->b.b.target != PIPE_BUFFER && !rtex->surface.is_linear) ||
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/util/os_memory.h:37
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31790>
All the post-merge pipelines are failing to be created with this error:
'shader-db' job needs 'debian-build-testing' job, but 'debian-build-testing' is not in any previous stage
Like all the other test jobs, shader-db should never run in post-merge
pipelines.
Fixes: 0724b00dad ("ci: run shader-db only when one of the drivers it tests is modified")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31758>
1. nightly takes a long, the extra few minutes for linking don't matter
2. nightly will run faster, since where it's CPU dependent it's at least +5% perf
3. it may reveal some painful areas of common code or driver.
4. for some jobs (not enabled yet, it generates ugly errors, disable
there
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28684>
The problem with radeonsi+ACO is that UBO loads from vec4 uniforms using
only 1 component always load all 4 components. This fixes that.
We are only interested in shrinking UBO and SSBO loads, but I added more
intrinsics because why not.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29384>
`shader-db` uses its output, and with its 8-10min runtime it can't be
ignored and should be counted with the other test jobs.
This makes the critical build jobs a bit slower but makes the overall
pipeline shorter when the test jobs respect the 15min deadline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31327>
Currently, our jobs which only want to run a little bit of python -
python-test and the LAVA jobs - pull the entire x86_64-build image,
which is both massive, and massively unnecessary.
Create a separate image which only carries what we need to run our
Python tests and utilities, and switch python-test to using that.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31151>
This was the only thing running shellcheck and pytest. Unsurprisingly,
tons of them regressed whilst it was gone. Since these have now been
moved to other jobs, we can just bring back debian-build-testing in the
non-critical-path stage if we drop LTO, so let's do that as there hasn't
been any movement towards fixing it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30978>
this existed for historical reasons, but realistically now it should
be possible to build mesa with dri3 always enabled. additionally,
this check was often used as a substitute for having drm functionality,
which is sort of similar but also not really a direct match
this simplifies a bunch of conditionals and prevents users from footgunnning
themselves into orbit
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30952>
Sometimes not all of the jobs execute. For instance, Windows build jobs
will not trigger on AMD-only MRs. Use the 'optional' keyword to ignore
jobs which don't exist in our pipeline.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 310e3bb026 ("ci: do not start build-only jobs until the critical build-for-tests jobs are done")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30926>
I think these were written with the idea of making it "(build rules) &&
(any relevant driver), but instead the driver rules are bypassing the
build rules because
1) it's not an AND, it's an OR; any line that matches applies, and
2) the driver rules are `when: on_success` when these need to be `when:
manual` like the rest of the build jobs.
Let's stop trying to be special and simply behave like all the other
build jobs.
We can always try making complex rules later, but once we're on a base
that works.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30871>
Specifically:
- `alpine-build-testing`
- `fedora-release`
- `.meson-arm` (inherited by all the arm build jobs)
- `debian-arm64` (because it overrides the inherited list)
- `debian-vulkan`
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30658>
