This fixes a number of regressions in Vulkan subgroups tests in CTS.
Fixes: 97f5721bfc ('broadcom/compiler: needs_quad_helper_invocation enable PER_QUAD TMU access')
cc: mesa-stable
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28797>
We take advantage of the needs_quad_helper_invocation information to
only enable the PER_QUAD TMU access on Fragment Shaders when it is needed.
PER_QUAD access is also disabled on stages different to fragment shader.
Being enabled was causing MMU errors when TMU was doing indexed by vertexid
reads on disabled lanes on vertex stage. This problem was exercised by some
shaders from the GTK new GSK_RENDERER=ngl that were accessing a constant buffer
offset[6], but having PER_QUAD enabled on the TMU access by VertexID was
doing hidden incorrect access to not existing vertex 6 and 7 as TMU was
accessing the full quad.
cc: mesa-stable
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28740>
The hardware do not support setting different polygon modes for front
and back faces at the same time. In this case, unless we are culling one
of the faces, we show a warning to the user.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28675>
With the simultaneous use flag we can reuse the same command
buffer multiple times. That means, for example, that we can
have an instance of a job running in the GPU while we are
submitting another one for execution to a queue.
This scenario is problematic with dynamic rendering and job
suspension because suspended jobs need to be patched with the
resume address at queue submit time, and thus, if we have another
instance of the same job currently executing in the GPU we could
stomp its resume address, which could be different.
To fix this, at queue submission time, when we detect a suspending
job in a command buffer with the simultaneous use flag, we clone the
job and create its own copy of the BCL so we can patch the resume
address into it safely without conflicting with any other instance
of the job that may be running.
We need to flag these clones as having their own BCL since
we would have to free it when the job is destroyed, unlike other
clones that don't own any resources of their own. Also, because
this job is created at queue submit time, it won't be in the
execution list of the command buffer, so it won't be automatically
destroyed with it, so we need to add it to the command buffer
as a private object.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28521>
This will be useful to know which is the actual executable
size of a BO in a CL that branches into a another BO. We
will need this soon to implement deep clones of the BCL
for suspending jobs with the command buffer simultaneous
use flag.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28521>
We had these pointing to the original job instead of pointing
to the cloned job. This can be confusing, particularly, if we
then emit commands that include references to new BOs into the
cloned jobs, since we would then try to insert these BOs in the
original jobs instead of the clones, which was the situation
we had when we implemented resume address patching with dynamic
rendering.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28521>
This will clone the job but it won't automatically put it in the
job list of a command buffer. This will come in handy to handle
the required job cloning for suspending jobs with the command buffer
reuse flag in a follow-up patch.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28521>
Multisync has been available in kernel releases for a long time
now and Raspberry Pi OS kernels have been supporting it for a
while too.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28541>
Reviewer the results from the last nightly run completed using ci-collate tool
(gl.fd.o/gfx-ci/ci-collate) with the 'patch' feature and a bit of human
intervention, these are the changes in the expectations.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28350>
Fixes crashes in tests like
dEQP-VK.pipeline.monolithic.render_to_image.core.2d_array.huge.width_height_layers.r8g8b8a8_unorm
with CTS main.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28364>
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>
This is achieved by the following steps:
#ifndef DEBUG => #if !MESA_DEBUG
defined(DEBUG) => MESA_DEBUG
#ifdef DEBUG => #if MESA_DEBUG
This is done by replace in vscode
excludes
docs,*.rs,addrlib,src/imgui,*.sh,src/intel/vulkan/grl/gpu
These are safe because those files should keep DEBUG macro is already excluded;
and not directly replace DEBUG, as we have some symbols around it.
Use debug or NDEBUG instead of DEBUG in comments when proper
This for reduce the usage of DEBUG,
so it's easier migrating to MESA_DEBUG
These are found when migrating DEBUG to MESA_DEBUG,
these are all comment update, so it's safe
Replace comment /* DEBUG */ and /* !DEBUG */ with proper /* MESA_DEBUG */ or /* !MESA_DEBUG */ manually
DEBUG || !NDEBUG -> MESA_DEBUG || !NDEBUG
!DEBUG && NDEBUG -> !(MESA_DEBUG || !NDEBUG)
Replace the DEBUG present in comment with proper new MESA_DEBUG manually
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28092>
Make the filename more descriptive and since the file is used by
multiple drivers, move it into appropriate util/ directory.
Cosmetics:
- use SPDX license tag
- add newline before main function
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27804>
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 was missing, this is implemented in common code.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28275>
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>
With dynamic rendering secondary command buffers can start subpasses
so we need this. Outside dynamic rendering secondary command buffers
won't be calling here since they are restricted to record commands
within a subpass.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
