I want the new version to show the fix in the fd-largeconsts branch (and
make sure the pass keeps working, and make sure other drivers get around
to fixing the issue). While I'm here, cherry-pick in the VK test along
with the GLES one, and also the fix for clip_three on ARMs.
Since the VK and GL test lists were changing, I took the opportunity to
reset freedreno xfails lists to just the tests that are being run with the
CTS uprev, and increase its coverage to 1/10th of the CTS across two
boards (since we just freed up a bunch of runtime with the grouped gles
"other" job).
For panfrost, I didn't spend the time characterizing the t720 fragment_ops
flakes like I did for the deqp-runner change. Given that the random
behavior changes between CTS versions, it doesn't seem to be worth the
time to do so.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
To increase our VK coverage on a630, we want to have two jobs in parallel,
but we still can't hit full coverage so we need the fractional setting to
be separate from gitlab CI's flags for setting up parallel jobs.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
This saves the minute and a half boot time on each of these minute-or-less
test jobs. The whole job was 3.5 minutes in my last run.
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
The recent change to install kernel modules for AMD included a sed job to
disable kernel modules in the defconfig. This somehow broke booting on
a307, except the commit failed to bump the arm64_test tag so it wasn't
noticed until the next uprev. (I didn't notice when landing the next
change to that container to add the deqp runner, because I didn't get a
git conflict on rebasing my tag bump so I didn't bump the tag again to
pull in the kernel changes and catch the fail).
I've spent a while trying to debug what's happened (including what
*should* be a replication of the kernel build on my local db410c) and come
up empty. Just punt and disable the AMD kernel module changes on
baremetal to fix it. Bump every container using lava_build.sh to make
sure we don't screw anything up with the script changes.
Fixes: 60c5729d16 ("ci: Distribute ADMGPU driver to LAVA as a module")
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
I found the C++ runner hard to develop on, and we had stability issues and
outstanding feature needs that made me want something I felt good about
hacking on. Thus, Rewrite It In Rust of the deqp runner.
The new runner includes:
- Skip lists don't reshuffle the test list.
- Known-flake handling without resorting to skip lists (fixing our main CI
reliability issue on a3xx right now).
- Per-thread Vulkan shader caches should speed up VK CI runtime.
- Tracking of crashes separate from fails (so we can see progress on that
front).
- Logging of deqp stderr spam (particularly assertion failures!) in the CI
log.
- Integrated QPA filtering so we don't have bash perf issues for it.
- Logging of what caselist to go look at for a given error report (in red,
so it's easier to find in your CI log).
- The code is 1/3 unit tests, and easy to extend for more coverage.
- Non-LAVA CI runs create a failures.csv in artifacts that you can check
in as your deqp-*-fails.txt file.
- Test runtime is included in results.csv so you can debug how to speed up
your CI job.
- Pretty summary at the end of the run of slow/flaky/failed tests.
Since this is a new runner with a different RNG, the test groups are
shuffled one more time. This seems to result in some panfrost T720
stability issues (See its new deqp-panfrost-t720-flakes.txt), and one new
flake in freedreno a630.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7434>
As it needs firmware to probe, and we cannot bundle it within the kernel
image because it is incompatible with the GPL.
Currently we rebind the driver after boot but that's slow and fragile,
as unloads of DRM drivers aren't generally tested.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7420>
So that if the former fails, build & test jobs won't run, wasting less
time & CI resources.
This requires slight tweaks to the rules: of the former job, to make
sure it always exists when the build jobs do.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7278>
These can catch various common issues in MR settings and Git commit
logs.
The "check mr" job only exists in pre-merge pipelines for MRs, and runs
automatically.
The "check commits" job only exists in pre-merge pipelines for MRs and
in pipelines for forked branches. It runs automatically in the former
case and can be manually triggered in the latter.
v2:
* Use git_archive docker image (Daniel Stone)
* Use a single sanity stage for both jobs (Tomeu Vizoso)
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6209>
We put it in the first container stage to prevent it from waiting for
jobs in previous stages, but empty needs: works for that as well.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6209>
I wasted a bunch of time today tracking down a spurious test results
change due to a driver invoking UB by running tests where NIR validation
had failed (instruction reading from components beyond vector size). If
we need to shrink our coverage to get runtimes down, it will still be
better to be catching validation errors in CI.
To keep the test jobs runtime under 10 minutes, I've split a530's gles2 to
two different jobs.
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7203>
In SDK 25 (Android 7, 2016), the kernel only went up to around 4.4, so
the upstreamed sync API didn't exist, and libsync didn't expose
sync_merge().
In SDK 26 (Android 8, 2017), the kernel is sometimes bumped to 4.9 or
4.14, but libsync has a sync_merge() that operates on either the
downstream or the upstream API.
Since our android-targeting drivers in general use sync objects (requiring
a kernel newer than 7 got) and sync_merge() (suggesting interaction with
external fencing that started in Android 8), make CI build against an SDK
version with the sync API. I think really doing SDK 25 right at this
point would involve backporting mesa with some #ifdefs to not expose sync
APIs that wouldn't work.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6821>
To support Android drivers, we're going to want to be tracking that Mesa's
build succeeds on a real android toolchain. This still uses the android
stubs since these libs aren't in the NDK.
Note that I had to drop the Intel and AMD drivers currently: we don't have
LLVM cross-compiled for Android in this container, and I'm honestly hoping
ACO saves us from that. Intel has dependencies on libexpat, which AOSP
really doesn't want to bring in, and it looks to me like those dependencies
could be optional.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6700>
This causes a lot of hiccups on the CL tests, but I've got most of
them fixed in another MR in pieces.
This should at least give a much more realistic baseline.
v2: use script in both places
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7073>
This adds support for building clover/llvmpipe and running the
piglit CL tests on it.
It uses the gl testing container, and add builds the libclc
spirv libraries as part of that which requires the llvm spirv
translator in the build container.
It also builds the llvm spirv translator as part of the build
root and creates a mesa build that builds clover for testing
against it. It uses llvm 10 as the baseline.
This drops bswap as it has an oob memory access with llvmpipe
which cause flaky test results. phatk also seems flaky
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6901>
The gles3 and gles31 multisample and 565-no-depth-no-stencil caselists
are also mustpass. And they don't add a significant number of extra
test cases.
The remaining mustpass caselists all involve rotation, which is not
currently supported in the surfaceless deqp build.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6553>
Some compile-time regressions go unnoticed because not all gallium
drivers are compiled as part of the meson-clang job. Let's pass an
explicit list of drivers to compile instead of setting GALLIUM_DRIVERS
to "auto" to increase CI coverage.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6811>
Since pre-merge pipelines run in the "mesa" namespace now, the rule
would have created the job if the source branch was named "master" (and
the job might have updated the public website).
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6566>
They are using a in source tree version of the needed libdrm
functionality or are shipping all needed headers in the source tree.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6672>
I'd like to see this new non-UAPI feature bake in CI. More importantly,
it may prevent some classes of flakes on cheza by isolating the processes
on the GPU so that a fault in one doesn't stomp over memory in another.
I've also pulled in a fix that etnaviv needed for their upcoming CI.
We add a few more kernel options while uprevving:
- More interconnect drivers for getting good GPU perf
- PRNG so that we don't get late-in-boot complaints about randomness.
- db820c's power domains and ethernet so hopefully we can switch to this
upstream kernel
This seems to slightly change the flakes happening in bypass mode, so add
them to the list.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6592>
Inform gitlab about the JUnit XML file that tracie produces, so that the
pipeline page can present more detailed information about tracie test
results.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6598>
Inform gitlab about the JUnit XML file that tracie produces, so that the
pipeline page can present more detailed information about tracie test
results.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6598>
Only in pre-merge pipelines for MRs, or in pipelines for forked project
branches.
Having the manual job in post-merge pipelines prevented the pages job
from running automatically as well, which could prevent the public
website from getting updated.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6534>
There's no need to have separate build scripts here, just choose what the
DEQP_TARGET is for the particular container being built. This brings in a
tremendous number of GLES test fixes that haven't made it into a tagged
gles CTS release.
Closes: #2056
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6526>
The version bump gets us various testcase fixes, mostly to test
requirements). While we're rebuilding the container, copy GL CTS stuff
from build-deqp-gl.sh -- we had already included the glcts binary in our
image, but we had unnecessary other binaries and were missing the mustpass
files (container size stays the same overall). Also pull in all the GLES
mustpass lists, not just the main ones -- Rob wants them to increase our
coverage to match what Android CTS covers.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6526>
Since the last GitLab update, pre-merge pipelines for MRs run in the
mesa/mesa namespace, so this job didn't get created anymore, causing
trouble.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6522>
