This is another secret change you've been waiting for 🐸
This change resets the current_offset value to 0 in ResetDescriptorPool
(without it the offset would keep counting until it reaches the limit
which causes allocation issues and/or application crashes/freezes)
RADV does the same thing, so I think this change is correct 🤓
BTW this meme seems to be relevant: https://youtu.be/1stQbTuUBIE
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
This is the secret change everyone has been waiting for 🐸
But anyway, this change adds the bufferImageGranularity limit (which
is needed by both DXVK and osu!lazer; DXVK will be a corrupted mess
without it and osu!lazer simply throws an exception)
The values have been scraped from https://vulkan.gpuinfo.org BTW
(because of that I'm not sure if they're actually accurate)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
This is what the blob advertises. I don't know if it's correct or not
because the CTS test for this seems to pass either way:
dEQP-VK.clipping.clip_volume.depth_clamp.point_list
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Here it is; the long-awaited change (as requested by 2 people on Discord 🥺)
This change originally added one Vulkan format which was needed for STK's
Vulkan renderer, but @gfxstrand suggested to add all of the A8B8G8R8_*_PACK32
formats in a GitLab thread)
This obviously fixes SuperTuxKart crashing with the Vulkan renderer 🐸
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
When multiview is enabled, queries must use N consecutive query indices in the
query pool, where N is the number of bits set in the view mask in the subpass
the query is used in.
In our case, only the first query is used, so we emit zeros for the remaining
queries.
Signed-off-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
The new helpers, now moved to nvk_mme.h, take an nvk_mme_scratch value
to ensure no overlap. They also ensure that we use exactly the same
register for the unspilled value as the spilled value. This makes
spilling safe for loop-carried values and the like. The old
nvk_mme_fill() helper just loads a spilled value to a new, possibly
different register.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
This helper unlike alloc, tries to use the same value as the register
had before. This is intended for manual spill/unspill code which wants
to keep register numbers the same while carefully spilling around high-
pressure regions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Introduce helpers to make it easier to work with the nvk mme shadow
scratch. Store begin in the shadow scratch in vkCmdDraw* related code to
save registers, which is necessary for Fermi.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Pre-Turing, we don't have a full condition built into the loop so, for
mme_while(b, ine, x, y) we have to generate the following:
[top] BR -> [cond]
/* loop body */
[cond] XOR tmp, x, y
BRZ !tmp -> [top]
However, due to an accounting error, we were generating
[top] BR -> [cond]
/* loop body */
XOR tmp, x, y
[cond] BRZ !tmp -> [top]
which meant that the XOR (or ADD if one is an immediate) was getting
skipped, leading to the loop either never terminating or always
terminating. The way to fix this accounting error is to close the while
first, then compute the condition value, then do the jump.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
We need to lock the memory objects list around the entire push builder
process. Otherwise, a memory object could get destroyed between adding
it to the BO list and doing the submit, leading to the kernel rejecting
our pushbuf.
When the time comes that we switch to the new uAPI both uses of
nvk_device::mutex will go away. We'll no longer be passing lists of BOs
to the kernel and we'll move to syncobj and be able to drop all the
nvk_bo_sync nonsense.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
We need 2 reports for these. One for successfully written primitives
and one for needed primitives. Also we need to use report semaphore's
sub_report member to specify the query's corresponding vertex stream.
Finally availability index is 2 in the query results, as we have 2
results for succeeded and needed primitives.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
