RGP expects shaders to be contiguous in memory, otherwise it explodes
because we have to generate huge captures with lot of holes.
This reduces capture sizes of Cyberpunk 2077 from ~3.5GiB to ~180MiB.
This should also help for future pipeline libraries.
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/13690>
Instead of mixing compilation and upload. This will allow us to
upload all shader binaries contiguously in memory and also for future
pipeline libraries work.
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/13690>
binary_out is never NULL and binaries are freed from the pipeline
after they are added to the cache.
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/13690>
If there is holes, eg. the application firsts set vertex attributes
0 and 1, then vertex attributes 0 and 7, the format of vertex attribute
1 is still the previous one, while it should be FORMAT_INVALID to avoid
a GPU hang.
This fixes a GPU hang with Yuzu.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5627
Cc: 21.3 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13856>
This has no effects, except for XFB but that shouldn't really matter.
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/13542>
The shader locations are now directly stored in radv_shader_args which
makes sense because they are tied to the arguments. The locations are
then copied to radv_shader_info but they will be moved into a new
radv_shader_binary_info with upcoming changes.
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/13542>
The game calls vkGetSemaphoreCounterValue() with an invalid semaphore
handle and it crashes. This is an invalid Vulkan usage and it should
be fixed in the game. I reported the issue to the developers.
Workaround this temporarily (hopefully) by ignoring
vkGetSemaphoreCounterValue() if the semaphore is NULL from an internal
RADV layer.
Cc: 21.3 mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5119
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/13956>
Detected by UBSAN.
../src/amd/vulkan/radv_private.h:2939:1: runtime error: member access
within null pointer of type 'struct radv_device_memory'
../src/amd/vulkan/radv_private.h:2926:1: runtime error: member access
within null pointer of type 'struct radv_buffer'
../src/amd/vulkan/radv_private.h:2945:1: runtime error: member access
within null pointer of type 'struct radv_image'
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/13965>
src/amd/compiler/aco_optimizer.cpp:1316:17: runtime error: shift
exponent 32 is too large for 32-bit type 'unsigned int'
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13951>
src/amd/vulkan/radv_cmd_buffer.c:3232:75: runtime error: index 252 out
of bounds for type 'uint8_t [128]'
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13951>
src/amd/common/ac_nir_lower_ngg.c:1135:62: runtime error: left shift
of 1 by 31 places cannot be represented in type 'int
src/amd/common/ac_nir_lower_ngg.c:622:20: runtime error: left shift
of 1 by 31 places cannot be represented in type 'int'
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13951>
This was plain broken. The solution is to not require any framebuffer
changes. Silently skipping results in broken behavior. e.g:
(secondary cmdbuffer with no framebuffer)
ClearAttachment 2
translated into
bind attachment 2 as attachment 0 (skipped)
clear attachment 0
restore original bindings (skipped)
which results in clearing attachment 0, not what we wanted. It is
a small wonder CTS doesn't find it until VK_KHR_dynamic_rendering.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13699>
They might not be available in secondary cmdbuffers with inheritance.
To avoid binding anything we need to create pipelines per attachment
index. I've excluded these from the "compile on device creation" set
because I think almost nobody will need them.
Alternative solution would be to reuse the same shader but muck with
a bunch of registers to shift them for the attachment index. That is
however a lot of complexity and has to execute on every pipeline
change, which is probably more expensive in overhead and definitely
in complexity.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13699>
If we have an inherited subpass in a cmdbuffer we can't really
emit any framebuffer data if it isn't provided.
Note we still do it for resolve clears, but we can't have that
in a secondary cmdbuffer with inherited renderpass.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13699>
In the following scenario:
CmdBindPipeline()
CmdBindVertexBuffers()
CmdSetVertexInput()
CmdDraw()
CmdBindVertexBuffers()
CmdSetVertexInput()
CmdDraw()
The VBO won't be updated for the second draw because the state is
cleared when the dynamic state is emitted and the pipeline isn't dirty.
Found by inspection.
Cc: 21.3 mesa-stable
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/13855>
When RADV_FORCE_FAMILY is used, this helps pre-compiling shaders to
make sure cache entries will match real hardware.
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/13812>
From the Vulkan spec:
"This parameter is ignored if templateType is not
VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_DESCRIPTOR_SET."
This fixes an assertion about the base object type when running Yuzu
with Vulkan validation layers enabled.
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/13846>
