This consolidates several duplicated pieces of code into devinfo.
max_scratch_ids is an array that provides the max number of threads
for the rendering and compute stages.
This fixes some exceptions missed by crocus for scratch ids on haswell
and cherryview.
It also fills out devinfo->max_scratch_ids properly for stages VS
through CS on Gfx12.5. But, functionally this should not make a
difference as Gfx12.5 already uses COMPUTE for all stages.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12799>
By default, Mesa's X11 Vulkan WSI will wait for buffers to be ready
before submitting them to Xwayland when the swapchain is created
with the IMMEDIATE mode.
This is undesirable when the Wayland compositor already monitors
fences. A Wayland compositor may want to know the delay between
the buffer submition and the end of the GPU work, this is impossible
to measure if the WSI waits for the buffer to be ready before
submission.
Since most compositors don't monitor fences, let's introduce a driconf
option for this for now. We can reconsider once more compositors
have better support for fences.
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11290>
For drivers that don't lower advanced blend to FBFETCH, we need the
bitmask to be in the NIR shader so that it gets carried over to TGSI
successfully.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12813>
this isn't the max per type, it's the max that can be used for a type,
which is the max used by a shader stage * the number of shader stages
Cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12829>
Clearing the first sample is enough as long as CMASK is also cleared
to indicate that other samples are also cleared.
I verified that the first sample is always at the beginning of 256B
blocks.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12483>
dEQP-VK.api.external.fence.opaque_fd.signal_export_import_wait_permanent
became a flake in latest kernel (5.10.60-v8+)
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12832>
Fixes instances of,
Error: Failed to parse dEQP-VK.ssbo.phys.layout.random.8bit.all_per_block_buffers.46 as CSV test,status[,duration] or comment at line 1
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12777>
VK-CTS v1.2.7.0 has buggy tests that only work if DRM support is
available for them (drm_files_exist). This isn't exposed in the Mesa
CI by other farms, because their infra installs libdrm-dev as part
of either rootfs generation for freedreno/broadcom or respective
container stages (for lava). In the case of radv, we directly use the
x86 Mesa testing containers, so we are the odd ones out here.
By moving the building of the custom libdrm above the building of
vk-gl-cts, it will compile in support required for this test to pass,
ensuring the x86_test-vk container has the right dependencies to match
the rest of the CI. Lava actually installs drm development files
twice, once from the Debian repos, which vk-gl-cts then compiles
against, and a second time from a tarball, which the tests will use at
runtime. Seemed a little cleaner to use the version of libdrm
specified in the Mesa CI, and hence used at both build time and
runtime.
A bug should be raised with the testsuite to avoid this in the future,
but we should probably have libdrm development files exposed for these
components anyway.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12777>
Dumps the command list, excluding the binary resources.
v2 (Juan):
- Make this option independent from `cl`
v3 (Iago):
- Rename option name
- Fix style issues
- Do not print BO ranges
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/12803>
any resource with active binds will have exactly 1 ref for the bind, so
if it also has usage, it needs to be destroyed on the batch to avoid
early deletion while it's in use
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12822>
left this out of the original 8/16bit storage implementation somehow,
but it didn't matter since nothing was doing 8/16bit ubo reads
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12823>
unrefs here (almost always) mean destruction, which means eating the cost
of the atomics for the unrefs and then also the destructors
instead, handle this at the end of the next submit from this batch, since the
submit thread is never as busy as the driver thread
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12759>
Jordan Justen
Simon Ser
Emma Anholt
Mike Blumenkrantz
Rob Clark
Samuel Pitoiset
Juan A. Suarez Romero
Charlie Turner
Bas Nieuwenhuizen
Ella-0