These values follow the already existing per-stage and descriptor set
limits. If we change these to be similar to the reported values of the
proprietary driver, care must be taken as Turing has bigger limits for
uniform buffers than older generations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
The hardware supports non-uniform access natively so we do not need to
lower most non-uniform access in the shader. Just lower the ubo access
as it should probably be faster when we uniformly load from real hw
ubos in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
We need to compute the allocated descriptor buffer size at descriptor allocation
time. So we need to split to a pre-computed size for all the other bindings
except the one with the variable count.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
On cases with variable descriptor counts we need to calculate the
maximum supported variable count while taking into account the other existing
descriptors and their alignments in the set.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
This brings in pretty much the radv opt loop.
So for tess ctrl where this a loop we can unroll, this fixes
some dynamic array access later to be non-dynamic.
Fixes:
dEQP-VK.clipping.user_defined.clip_distance_dynamic_index.vert_tess.1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
We need to keep some context for the compilation of the tessellation shaders.
This is required in the case where the domain is specified in the
tessellation control shader instead of the tessellation evaluation
shader, as codegen needs the domain information when compiling the
tessellation evaluation shader.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
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>
