Now that these can come from different releases, with different sets of
patches backported to them, it matters that we use the correct one.
Fixes: 78ea3bb43d ("ci/deqp: use the proper gl/gles releases for deqp-gl*, deqp-gles*, deqp-egl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28343>
Currently 92% of our Vulkan CI tests hit "Not Supported" test
cases, which is ridiculously high. Add a bunch of skips, some
of which include very large categories of tests of features we
already know we don't support, so we stop wasting so much time
skipping tests.
With this, we can also increase the fraction of tests we execute
for vulkan significantly, while still keeping job run times
under control.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28264>
A big chunk of the new flakes and timeouts are caused by enabling new
tests in f977e4d4f5 ("v3dv: Enable
EXT_swapchain_maintenance1").
I'm not quite sure what happened with
`dEQP-VK.wsi.wayland.swapchain.simulate_oom.*` but now at least half of
them are flaky on rpi4 (between Skip and Crash), so moving the whole
block to flakes. On rpi5 I haven't seen them flake yet so tentatively
removing them entirely, but there's a good chance the issue is common
and they'll have to be put into flakes on rpi5 at some point as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28316>
This is a known bug in CTS affecting a number of tests in the
renderpass, renderpass2 and dynamic_rendering categories, but
it seems this is the only one triggered by CI. The bug has been
fixed in CTS 1.3.7.3.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
These start executing with dynamic rendering, and despite the name,
they don't actually require shader object. The reason they fail
is a bug in CTS (main).
Note: these are a crash in CI, but in CTS main they are a Fail.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
We want these as skips instead of fails because there are many tests involved
and not all of them fail, so every time we add a new feature and change the
subset of tests we run in CI we start hitting different tests and we have
to keep patching the list, so just move them to skips since we know we don't
support them and we should not be running them.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
Avoids flushing jobs that write a texture that is read by a job in the
same job submission.
Now we need to handle the case where a texture is written by the
graphics pipeline and it is read by a compute pipeline.
Before this patch, glTextureBarrier() could be implemented as a NOP in
v3d. So the driver was doing more flushing than needed when
glTextureBarrier was not used.
v2: Use V3D_FLUSH_ALWAYS for resources written by graphics pipeline
and read by compute insead of V3D_FLUSH_DEFAULT. (Iago Toral)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27550>
It seems the hardware behavior for this is as per-spec and we are
supposed to identify as active entire quads. Particularly, there
are some derivative tests with dynamic control flow that use
subgroup ballot and require this.
However, we still need to exclude terminted lanes (OpTerminate). For
that, we keep track of the sample mask at the start of a fagment
shader start and compare it with the current sample mask.
Fixes: ('broadcom/compiler: support subgroup reduction operations from fragment shaders')
Fixes: dEQP-VK.glsl.derivate.dynamic_loop.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27409>
We are slightly over-subscribed right now, with 21 merge jobs (10 vk
+ 10 gl + 1 traces) for 20 RPi4, so let's split the tests between
slightly fewer RPi4 and make each split job run for slightly longer,
because it also means that all the jobs start immediately, reducing the
overall delay in merging any MR that triggers this job.
The typical run time for this job was around 8 min with a 10-split; with
an 8-split it is now 9 min, which is still within the 10 min target and
well below the 15min limit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27391>
