this is a partial barrier, so having access of any kind is invalid
VUID-vkCmdPipelineBarrier-srcAccessMask-02815(ERROR / SPEC): msgNum: 618171435 - Validation Error: [ VUID-vkCmdPipelineBarrier-srcAccessMask-02815 ] Object 0: handle = 0x2834530, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x24d88c2b | vkCmdPipelineBarrier(): .pImageMemoryBarriers[0].srcAccessMask bit VK_ACCESS_TRANSFER_READ_BIT is not supported by stage mask (VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT). The Vulkan spec states: The srcAccessMask member of each element of pMemoryBarriers must only include access flags that are supported by one or more of the pipeline stages in srcStageMask, as specified in the table of supported access types (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-srcAccessMask-02815)
Objects: 1
[0] 0x2834530, type: 6, name: NULL
zink DEBUG: ERR: 'Validation Error: [ VUID-vkCmdPipelineBarrier-srcAccessMask-02815 ] Object 0: handle = 0x2834530, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x24d88c2b | vkCmdPipelineBarrier(): .pImageMemoryBarriers[0].srcAccessMask bit VK_ACCESS_TRANSFER_READ_BIT is not supported by stage mask (VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT). The Vulkan spec states: The srcAccessMask member of each element of pMemoryBarriers must only include access flags that are supported by one or more of the pipeline stages in srcStageMask, as specified in the table of supported access types (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-srcAccessMask-02815)'
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12845>
It only makes sense to call this pass for fragment shaders, and the
first thing the pass does is read a FS-specific field out of a union,
so it isn't safe to call it for other shader stages.
We could make it early return, but instead we just assert, so that
drivers know to only call it when appropriate.
(A previous version of this patch, which early returned instead of
asserting, was Reviewed-by: Emma Anholt <emma@anholt.net> as well.)
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12839>
i965 called this pass unconditionally, while st/mesa only calls it for
fragment shaders. It only makes sense to run for fragment shaders, and
the first thing the pass does is read a FS-specific field out of a
union. This isn't safe for other stages.
Fixes about 20,630 test failures on i965 since 91dc863921, which moved
the advanced_blend_modes field. The field had previously been in a
union with no other fields, so it never aliased anything, and thus
worked, even if it was wrong. That commit moved it to a union that had
fields for other stages, so it started reading garbage and trying to
lower advanced blending for other stages on i965.
Fixes: 91dc863921 ("mesa: Move the advanced blend bitmask to shader_info.")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12839>
this reduces the component key size for decomposition by up to 75%, down
to as low as 2 bytes, which is more optimal for both hashing and memcmp of
the key
it will become more useful as further changes are added to improve vertex format
support, enabling the keysize to remain relatively small
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12771>
`hasAttribute()` in `llvm::AttributeList` is gone, use `hasParamAttr()` instead.
This fixes an FTBFS.
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12826>
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>
