Move the memstream code into common code. Other Rust code interfacing
with FILE pointers will find the memstream abstraction useful.
Most notably, pinning is actually enforced this time with PhantomPinned.
Add a .clang-format from a sibling dir (i.e.: compiler/nir) while we're
at it to keep things tidy.
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30594>
With DRLR, we unfortunately don't get notified about when there are
feedback loops. We also can't detect ahead of time the case where an
input attachment is read before written. This means we need to try and
guess in the driver when that happens based on which input attachments
we read.
There are three main things we have to do with feedback loops:
- Forcing flushing between primitives in sysmem to avoid problems with
compressed textures before a7xx.
- Forcing late depth test if it's a depth feedback loop.
- Invalidating UCHE because we may read blit results.
The way this is implemented is currently a bit conservative, following
radv. However the impact of the flushing should be mitigated by
switching to GMEM whenever we can, which we already do.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31261>
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>
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>
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>
Georg Lehmann