When a descriptor gets freed because a buffer/image veiw or sampler is
deleted, zero out the descriptor memory. This prevents the descriptor
from being used later and faulting on possibly non-existant memory.
While we're here, clean up the function a bit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
The new api returns a VkResult for more accurate error checking. More
importantly, it also does copies the descriptor data into the table
instead of returning a map. This means the users of the descriptor
table will never see a map and we can make sure that the copy happens
under the lock in case we have to grow. Since each descriptor is only
32 bytes, this isn't going to be a perf problem.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
When Dave originally added SLM, he did so with a preamble pushbuf which
sets up the SLM area prior to executing any actual command buffers.
This has the advantage that the SLM BO is never directly referenced in
any command buffer and we can swap it out even after command buffers
have been built. When I added image/sampler tables, I sort-of went
along with it but then did something different for 3D.
Thanks to buffer reference counting, we can employ a fairly simple
locking scheme. Each of the globals: images, samplers, and TSL has a
lock which gets taken whenever the table is modified. When we go to do
a submit, we take each lock and take a queue-local reference to the BO
and grab a copy of its size parameter under the lock. If anything has
changed, we update the queue-local preamble pushbuf. Because the queue
also holds a reference, we can safely proceed to submit command buffers
which reference those global BOs without the individual global locks
taken. If SLM or one of the descriptor tables resizes while we're
mid-submit, our reference to the BO will remain valid until either the
destruction of the queue or the next submit.
The one small bit of threaded cleverness (one always has to be careful
with that) is that the SLM size can be checked without taking the lock
because the SLM size only ever increases.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
The MAX_MIP_LEVEL field needs the actual number from the image because
it's used to compute the stride between layers. The restrictions on mip
level come entirely from the RES_VIEW fields.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Previously, it was treated as luminance and the depth or stencil
component was broadcast to all channels except alpha. In Vulkan, depth
and stencil textures are treated as red. If we want it treated
differntly by some other API, that driver can do that with a swizzle.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Instead of invoking the meta code, implement it ourselves so we get the
HW clear path. We could probably put these implementations somewhere
common since they only set up a few things and invoke Begin/EndRendering
but there's not that much point for now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Fixes the following building error:
../src/vulkan/runtime/vk_meta_clear.c:213:42: error: use of GNU empty initializer extension [-Werror,-Wgnu-empty-initializer]
struct vk_meta_clear_push_data push = { };
^
1 error generated.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
KHR_get_memory_requirements2 was enabled but GetImageMemoryRequirem
ents2 was not. This stubs out GetImageMemoryRequirements2 to fix it.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
v2: remove the v1 version of the command as its provided by the
common runtime
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
vulkan spec says:
If the memory object is allocated from a heap with the
VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT bit set, that object’s
backing memory may be provided by the implementation lazily. The
actual committed size of the memory may initially be as small as
zero (or as large as the requested size), and monotonically
increases as additional memory is needed.
As far as I can tell we ignore the bit meaning that we allocate the
requested size so return that as the size.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
This values was found by trial-and-error poking at the hardware until it
stopped complaining. It's not clear if we need separate values for
compressed vs. not. This appears to work on Turing regardless of what
we set for SET_Z_COMPRESSION.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
