debian-testing is the critical path: the shortest possible job to build
exactly what we need to execute on hardware, and nothing else.
debian-build-testing exists to give us better coverage at the expense of
running longer.
Since the only jobs using r300 and Nine, and the only jobs using NVK,
are in post-merge stages which are manually triggered, move these builds
to debian-build-testing. This makes the critical path to those a little
longer, but we do get to make it shorter for everyone else just running
regular Marge jobs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
LLVM 15 is pretty old, and notably not supported by either ANGLE nor
Skia anymore. So let's move up to LLVM 19 using packages provided by
LLVM themselves, apart from PPC and ARMv7 which don't have builds.
The Skia build now requires a bunch of new warning exclusions; hopefully
most of these are no longer needed when we can upgrade Skia shortly.
The ci-deb-repo revision has also been bumped to get us a new version of
xtensor which builds with LLVM 19, and a version of spirv-tools which
also works with LLVM 19.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Closes: mesa/mesa#11538
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Sitting here trying to get something else done tonight, I watched the
ASan and UBSan jobs, both on AArch64 and x86_64, regularly blow through
their timeouts.
They should be fixed to do less, but this makes them at least succeed in
the meantime.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Building and linking drivers, Rust code, and tools, takes an inordinate
amount of time with sanitisers. That could be justified if we used the
results to test, but we don't.
Reduce the coverage to get reasonable runtimes back.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Running the Meson tests doesn't take forever, but it does take a
noticeable amount of time.
For jobs in the critical path - like debian-testing and debian-arm64 -
we need them to complete as soon as possible to produce a build for the
hardware tests to consume. Running the tests here lengthens that time,
and introduces more hazard since the tests have previously been prone to
hitting timeouts, requiring the whole job to be retried before we can
proceed. These jobs also have build-only jobs which are not in the
critical path, and can run the tests just as well.
Running the tests under sanitisers is just too slow to deal with in
pre-merge pipelines.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
In order to build the mesa llvmpipe driver for Android, llvm libraries
for Android are needed; force meson to use a fallback for llvm and
provide prebuilt libraries making them available to meson thanks to
a wrap file.
Enable other software drivers for the x86_64-linux-android build, but
also disable the amd and intel hardware drivers for now which don't
build correctly on Android.
Download the prebuilt LLVM libraries for Android in the container job
rather than in the build job, to avoid downloading some big artifacts
for every mesa version built for Android.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Currently the python-test job runs pytest and then creates python
related artifacts for use by other jobs. But the python-test job isn't
triggered by changes to the python scripts and libraries. Instead, changes
to python scripts and libraries can currently be merged without running
pytest and, if they do generate errors, they will only appear in ci
later when trying to generate the python artifacts.
Add pytest to the existing linting jobs and expand the rules so that it
will be triggered by changes to python scripts and libraries. Remove
pytest from the job that creates artifacts. This will ensure that the
artifacts are still valid while catching script/library errors before they
are merged.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
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>
Martin Roukala (né Peres)