When creating and caching the bo_export object for a given zink_bo, the
screen file descriptor was used. Since no buffer object's file descriptor
would match that, bo_export objects were continuously added to the exports
list and no bo_export was effectively picked from the cache. Using the
buffer object's file descriptor avoids that.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: b0fe621459 ("zink: add back kms handling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31715>
Based on the original code from sp_tex_sample.c,
this was supposed to be a comparison with pmax2,
not pmin2.
This mostly seemed to result in anisotropic filtering
turning on to "maximum" at any value of max_aniso > 1.
Most apparent when runing the texfilt test in demos.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31562>
We need to pass through the robust_modes flag to nir_opt_vectorize based
on a flag set when compiling the shader, not globally in the compiler,
for VK_EXT_pipeline_robustness. Refactor the ir3 compiler interface
to add an ir3_shader_nir_options struct that can be passed around to
the appropriate places, and wire it up in turnip to the shader key. The
shader key replaces the old mechanism of hashing in the compiler
options.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31687>
Always enable the level covering the whole FB, and disable the finest
levels if we don't have enough to cover everything.
This is suboptimal for small primitives, since it might force primitives
to be walked multiple times even if they don't cover the the tile being
processed. On the other hand, it's hard to guess the draw pattern, so
it's probably good enough for now.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31682>
When flushing the render target cache for future operations, we need a
stall at pixel scoreboard. We likely didn't see any issue until now
because a change in render target added the pb-stall.
When using a 2 compute shaders with the following pattern :
vkCmdDispatch()
vkCmdPipelineBarrier() ImageBarrier with (src|dst)AccessMask=0 & identical layout
vkCmdDispatch()
we should ensure that the first dispatch is completed before executing
the second one, otherwise they can race to on resource accesses. This
fixes failures in some new CTS tests.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31676>
This assumes that the best case jump latency is higher than the worst case
ALU latency.
Foz-DB Navi31:
Totals from 17720 (22.32% of 79395) affected shaders:
Instrs: 26009663 -> 25929989 (-0.31%); split: -0.31%, +0.00%
CodeSize: 136571496 -> 136254420 (-0.23%); split: -0.23%, +0.00%
Latency: 215731308 -> 215722059 (-0.00%); split: -0.01%, +0.00%
InvThroughput: 36534197 -> 36532070 (-0.01%); split: -0.01%, +0.00%
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31132>
there was some confusion over exactly where ici->usage should be set,
since the value must be set when doing all the format checks but then
also it was re-set again later to a potentially different value based
on an unchecked return
now get_image_usage() is set_image_usage() with a more consistent policy
around exactly where the usage is set
this code still sucks tho
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31686>
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>
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>
