Otherwise, once we need to grow past 2^17 B, we attempt to copy two
lines, the hardware errors out, and we get left with a junk heap.
While we're here, re-arrange the code a bit so we keep all the P_FOO
together.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
DXVK versions before v1.5.5 need this format in some cases
I haven't tried running CTS yet, but GTA San Andreas runs
well now on DXVK v1.5.1 (before this change it crashed) so
I think CTS should be happy enough 🐸
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Check view_mask inside the macro to determine which loop to run. In
emit_clear_rects(), move code out of if/else that is the same in both
branches.
Signed-off-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
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>
