Now that we have a common pipeline layout with reference counting, we
don't need these driver hooks for reference counting anymore.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17286>
There's some tricky stuff in here with properly handling Vulkan
allocation scopes and reference counting. Probably best to do it once.
Also, this means that common code can now take references to descriptor
set layouts which seems useful.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17286>
D3D12 wants Width, Height and Depth to be aligned on the block width,
height and depth size. But Vulkan allows the width, height or depth to
be unaligned at the image boundary if image.{width,height,depth} is
not aligned.
Let's explicitly align things in the copy paths.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
D3D12_RESOURCE_STATE_DEPTH_READ only provides access for fixed-function
depth/stencil test. If we want the shaders to be able to read the
depth/stencil attachment, we need to combine
D3D12_RESOURCE_STATE_DEPTH_READ and
D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
Sometimes there's no obvious mappings between a VkImageLayout and
a D3D12_RESOURCE_STATE, so let's just provide a helper that takes
before/after resource states instead of old/new layouts, and use it
to fix the resolve case.
Fixes: 35356b1173 ("dzn: Cache and pack transition barriers")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
We are about to introduce the same function taking D3D12_RESOURCE_STATES
arguments instead of VkImageLayout ones. Let's rename the function
accordingly.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
We want to pack ResourceBarriers() call as much as we can, so let's
not dzn_cmd_buffer_queue_transition_barriers() when we could still queue
new barriers.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
Some Vulkan -> D3D12 API mismatches force us to do behind-the-scene
transitions to get resources in the right state when executing
non-native operations. In this case, caching the transition until the
resource is actually used might save us unneeded transitions.
The packing aspect is mostly useful to limit the ExecuteBarriers()
call overhead. Right now we do per-resource packing, and any hole
in the subresource range will trigger several ExecuteBarriers()
calls. This can be improved by collecting barriers in a separate
array, and flushing the collected transition barriers just before
executing the operation using the subresources pointed by those
barriers. While not impossible, it'd be more verbose than what we
have right now, so I'm not entirely convinced it's worth it.
Caching could be improved to avoid any unnecessary flush when we do
blit or copy operations and transition the resources back to their
original state, since the user might decide to transition the image to
a new layout just after that. But doing that would require keeping
track of all resources used by dispatch/draw operations, which in turn
implies keeping info about which of the descriptor set resources are
used by the graphics/compute pipelines. Not sure the it's worth the
extra complexity given D3D12 enhanced barriers are just around the
corner, and those map pretty nicely to the vulkan barrier+image-layout
model.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17274>
24be011901 ("lima: wire up MSAA 4x support") switched to aligning all the
buffers to tile size and it resulted in allocating 16x more memory for
index, vertex and constant buffers.
We only want to align textures and render targets to tile size, not
other buffers, so restore old logic, but relax it.
Fixes: 24be011901 ("lima: wire up MSAA 4x support")
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17283>
They aren't supported and lead to GPU hangs.
Reported-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
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/17256>
The feature we wanted to enable in 710393b3aa was
descriptorBindingUniformBufferUpdateAfterBind.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 710393b3aa ("anv: enable UBO indexing")
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17200>
This is hit using lavapipe with zink on top running
dEQP-GL45-ES31.functional.primitive_bounding_box.wide_points.global_state.vertex_tessellation_fragment.default_framebuffer_bbox_equal
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17270>
When the stencil aspect of a depth+stencil texture is sampled, it's
actually integer. Also fixup st_translate_color() that assumed it was
float. This fixes the border color on zink+turnip.
v2: Add "|| texBaseFormat == GL_STENCIL_INDEX" to catch the case where
S8 is emulated as D24S8.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
On a650+ we use the new Z24UINT_S8UINT format to sample the stencil
aspect of D24S8, which returns stencil in the second component and also
uses the second integer component for the border color. However Vulkan
mandates that the first component is used for the stencil border color.
There's no workaround we know of, so we have to fall back to the old
behavior where there is a workaround. If we know the format, we can
fixup the border color ourselves though.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
From the API's point of view, border color replacement looks like this:
--------------------
| API Border Color |
--------------------
|
----------- | ---------------- ----------
| API fmt |-------->| User Swizzle |----->| Shader |
----------- ---------------- ----------
From the HW point of view, it looks like this:
-------------------
| HW Border Color |
-------------------
|
---------- ----------- | --------------- ----------
| HW fmt |-----| HW swap |------>| Tex Swizzle |----->| Shader |
---------- ----------- --------------- ----------
When the HW fmt + HW swap isn't enough to represent an API format, we
need to prepend our own swizzle to the the user's swizzle, so the tex
swizzle is a "format swizzle" composed with the user swizzle. However,
we don't want this format swizzle to be applied to border colors, so
there's a workaround in freedreno which is meant to undo the format
swizzle so that the HW border color with the format swizzle applied
equals the API border color, and everything is ok. However, on a6xx at
least it was incorrectly undoing the entire tex swizzle. This broke
border color with a user swizzle, because it was now effectively not
getting applied for the border color. It also made it seem like the user
swizzle is required for the workaround, which would have implications
for VK_EXT_border_color_swizzle with turnip, but it's not.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
virgl: Also drop old pre-trim glxgears trace (cached).
Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Emma Anholt <emma@anholt.net>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17280>
LAVA job logs have an ongoing problem of message interleaving with kmsg.
So any kernel dumps and LAVA signals (which are being printed in kmsg)
will have a chance to clutter the pattern matching for `hwci: mesa:
(pass|fail)` line.
v2:
- Add an 1 second sleep before exiting the test script, to give enough
time to print the result message without conflicting with LAVA ENDTC
signal from kmsg
Closes: #6714
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17175>
Early depth test is broken when the linear render target mode is used
and depth is written from the PE stage. It seems RA and PE disagree
about the cache layout in that case, so the RA sees unwritten/invalid
depth cache lines leading to random depth test fails. Early test works
fine if depth is written from the RA stage.
To work around this issue, detect the combination of linear RT, early
test and late write and switch to late test in that case.
Fixes: 53445284a4 ("etnaviv: add linear PE support")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17215>
On-GPU LRZ direction tracking allows LRZ to support secondary cmdbufs,
reusing LRZ between renderpasses, and in future to support LRZ when
VK_KHR_dynamic_rendering is used.
With on-gpu tracking we have to be careful keeping LRZ state in sync
with underlying depth image, which means we should invalidate LRZ
when underlying image is changed or the view of image is different
from previous renderpass.
All of this resulted in LRZ logic being thinly spread through the code,
making it hard to understand. So most of it was moved to tu_lrz.c.
For more details on past and new LRZ features see comment at the
top of tu_lrz.c.
Note about blob:
- Blob is much more happy to do LRZ_FLUSH, it flushes at the start
of the renderpass, after binning, and at the end of the renderpass.
- Blob seem not to care about changes in depth image done via
vkCmdCopyImage.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6347
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16251>
Christian Gmeiner
Jason Ekstrand
Boris Brezillon
Michel Zou
Juan A. Suarez Romero
Hyunjun Ko
Lionel Landwerlin
Vasily Khoruzhick
Samuel Pitoiset
Dave Airlie
Mike Blumenkrantz
Connor Abbott
Timothy Arceri
Sil Vilerino
Jesse Natalie
David Heidelberg
Konstantin Seurer
Guilherme Gallo
Lucas Stach
Danylo Piliaiev