In gallium samplers and textures have a 1:1 correspondance, so it was
impossible to tell which is which. But we use non-bindless textures for
subpass loads, which don't have a sampler (so common code lowers to an
index of 0) and therefore the order matters. With dynamic rendering, we
can have more than 16 slots for input attachments, so the s2en wasn't
getting optimized away and suddenly it starts mattering, and it turns
out we got it wrong. By fixing this we also make the order the same as
the bindless order, which was always tested well by Vulkan.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31261>
With VK_KHR_dynamic_rendering_local_read we can have input attachments
with no index, which normally correspond to depth/stencil attachments,
and we have to handle this here when determining whether we need to emit
an unscaled fragcoord for FDM.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31261>
This will let us know when an input attachment doesn't have an
InputAttachmentIndex, which used to be illegal but is now allowed and
meaningful with VK_KHR_dynamic_rendering_local_read.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31261>
The code seems to assume that it's supposed to be a base index for the
binding array, but it's not. It's entirely meaningless and happens to be
set to 0 for all descriptor types except for input attachments, which is
the one case where it's already ignored. Delete the dead code so that
when we change it to a "no index" sentinel value v3dv doesn't blow up.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31261>
Tilers need to know, at the very least, which input attachments are
"real" input attachments which map to a color or depth/stencil
attachment in tile memory and which are "fake" input attachments that
should be treated as regular textures. To do this we need to know
VkRenderingInputAttachmentIndexInfoKHR::colorAttachmentCount, which
wasn't provided by the state tracking infrastructure. When the
VkRenderingInputAttachmentIndexInfoKHR isn't provided, we don't know it,
though, so we have to record a special UKNOWN value. In that case, the
driver will know thanks to
VUID-VkGraphicsPipelineCreateInfo-renderPass-09652 that all input
attachments are "real" input attachments that map directly to color
attachments if they have an InputAttachmentIndex.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31261>
Currently, we:
* copy the case list to a temporary file
* have sed read it in, decimate for fraction, write it out again
* have sed read it in, decimate for shard, write it out again
Flatten this out to have a single-pass sed covering both fraction and
shard that reads the source caselist in directly and writes the final
one.
This comes at the cost of an expression that's unreadable even for sed,
but with the Vulkan mustpass over 400MB and growing, it's a good
improvement.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31595>
We previously only had two traces (one for Raven, one for lavapipe)
running via Wine. To support this, the Vulkan container had Debian's
full Wine installation, one from DXVK, and then a third from Proton
which is used by the b2c jobs.
At 600MB each, this was pretty unsustainable. Remove everything but the
Proton ones.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31595>
The radv-raven and lavapipe trace jobs were using Wine installed from
Debian. lavapipe had a single post-merge trace running, and raven had
all but one trace disabled due to being flaky.
b2c is using Proton instead, and it makes absolutely no sense to have
two parallel versions of Wine installed. These should be brought back at
some point running on the same version of Wine as the newer b2c jobs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31595>
One quirk of the shfl instruction is that it only works with dynamically
uniform indices. This commit adds a pass to lower shuffles to the
ir3-specific ones using a loop that iterates all distinct indices one by
one. This is based on the blob's sequence.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31501>
Coverity notices that we've insured that index index is < MAX_RTS in one
case, but that it must be greater in one case. Since `color_att_count`
is a uint32_t, it can easily exceed MAX_RTS (8), and would thus create
an out-of-bounds read situation. While the type system would allow this,
the actually implementation shouldn't, so an assert should make Coverity
happy and help us check our assumption.
CID: 1620440
Fixes: d2f7b6d5a7 ("anv: implement VK_KHR_dynamic_rendering_local_read")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31640>
Since deqp-runner is already being built in the debian base image for test
jobs, it’s not necessary to build it subsequently in GL and VK debian
test images. Update the image tag instructions for uprevving deqp-runner.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31429>
Since the 'git clone --branch' option only accepts branch names or tags as
arguments, it’s not currently possible to build deqp-runner directly from
a git commit hash.
Revise the deqp-runner build script so that it can build from a commit
even if it doesn’t have a tag or version number.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31429>
Opaque fds are internally dma-bufs. We also support both export and
import. But for dma-bufs, we additonally require the image tiling
allows vkGetImageSubresourceLayout for export and
VkImageDrmFormatModifierExplicitCreateInfoEXT for import.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31649>
Connor Abbott