vkCmdBindVertexBuffers() -> draw with mesh shaders will just segfault.
This sequence doesn't make real sense but it's possible.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41161>
The Vulkan spec says:
"VUID-vkCmdExecuteGeneratedCommandsEXT-None-11062
If a rendering pass is currently active, the view mask must be 0."
So, it's invalid with VK_EXT_device_generated_commands but it's allowed
in DX12, it seems we missed this during the spec review.
Crimson Desert uses this and emulating in vkd3d-proton would be complex,
so let's re-introduce this support only for vkd3d-proton.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41153>
Reported by clang tools.
See: https://clangd.llvm.org/guides/include-cleaner
struct ac_cmdbuf had to be moved to ac_cmdbuf_base.h because we can't
include ac_cmdbuf.h->sid.h->amdgfxregs.h in radeon_winsys.h for r300.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41091>
KHR_pipeline_library is a base extension whose semantics can only
be exercised by extensions: EXT_graphics_pipeline_library
and KHR_ray_tracing_pipeline. Both remain gated under LLVM,
so advertising the KHR base extension is inert for conformant apps.
The reason for the change is a hard requirement for KHR_pipeline_library
in DXVK 2.7+. DX games under Proton, which uses DXVK, fail adapter
creation if this extension is absent. DXVK supports scenario when
KHR_pipeline_library is available but two dependent extensions aren't.
The !use_llvm condition originated in f1095260a4 when
KHR_pipeline_library was first wired up for ray tracing only. It was
touched also in 045c96d896 when EXT_graphics_pipeline_library also took
it as a dependency.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41134>
This prevents the compiler to access the logical/physical devices and
the instance during compilation.
The main goal is to make it more robust against cache related issues
when something isn't hashed correctly (this used to happen a lot in the
past). Also it would be much more robust for sharing binaries between
two GPUs in the same generation (eg. Vangogh/Rembrandt) because
everything needed for compilation is in radv_compiler_info. There is
still some work to do to achieve that but it's making good progress.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40992>
V_581B_PFP and V_581B_ME is for pws acquire_mem. Current code
does not cause any problem because we won't pass engine arg
directly to acqure_mem packet. But use a native V_581A_* arg
for better coding.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41069>
New IB print will assert reserved packet field to be zero.
Fixes: 1c75cd958f ("ac: enable the new auto-generated CP packet parser")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41069>
The previous fix was incomplete because if the same graphics pipeline
and the same PS epilog are rebind after vkCmdExecuteCommands(), the PS
epilog state wouldn't be re-emitted, and it will use a wrong VA (in case
both fragment shader user SGPRs aren't similar either).
Resetting the PS epilog to NULL in the primary should prevent any
issues, but this tracking still need to be improved because it caused
two issues recently.
Fixes: 1a00587c44 ("radv: fix a GPU hang with PS epilogs and secondary command buffers")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15176
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41056>
With SPV_KHR_constant_data, it's allowed to specialize array of
constants.
RustiCL changes are from Karol Herbst <kherbst@redhat.com>.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41046>
Latest addrlib supports SIMD (AVX2) and it's definitely fast enough to
be used in production now.
GFX10 is still not enabled by default due to some regressions from the
addrlib bump, also still missing AVX for some formats.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40996>
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40917>
Fixes the following building errors:
../src/amd/vulkan/radv_rra.c:1369:43: error: use of GNU empty initializer extension [-Werror,-Wgnu-empty-initializer]
struct radv_bvh_stats_gfx12 stats = {};
^
../src/amd/vulkan/radv_rra.c:1376:45: error: use of GNU empty initializer extension [-Werror,-Wgnu-empty-initializer]
struct radv_bvh_stats_gfx10_3 stats = {};
^
2 errors generated.
Fixes: 8c10eab1 ("radv: Add an option for dumping BVH stats")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41011>
Fixes the following building errors:
../src/amd/vulkan/radv_shader.c:3460:42: error: use of GNU empty initializer extension [-Werror,-Wgnu-empty-initializer]
struct radv_shader_debug_info debug = {};
^
1 error generated.
../src/amd/vulkan/radv_shader_args.c:975:43: error: use of GNU empty initializer extension [-Werror,-Wgnu-empty-initializer]
struct user_sgpr_info user_sgpr_info = {};
^
1 error generated.
Fixes: 480a94fb ("radv: Gather debug info about shader args")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41011>
Applications are required to set NonUniform if the resource is arrayed,
but with VK_DESCRIPTOR_MAPPING_SOURCE_HEAP_WITH_SHADER_RECORD_INDEX_EXT,
the resource is non-arrayed in the shader. So, it's technically not
required to set it. Although, the offset can vary per-lane and
NonUniform is implicit.
Backport-to: 26.1
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40953>
With the previous commit ("ac/surface: Filter swizzle modes for VCN"),
only video-compatible swizzle modes will be picked, so we can enable
tiling for VCN2+.
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40948>
The recent addition of PIPE_FORMAT_X6R10X6G10X6B10X6A10_UNORM caused
vk_format_to_pipe_format() to map VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16
to a real pipe format, which made radv_physical_device_get_format_properties()
advertise BLIT_SRC/SAMPLED_IMAGE for it. The hardware samples the data as plain
R16G16B16A16 UNORM, which doesn't match the 10-bit UNORM semantics the spec
(and CTS) require, so dEQP-VK.api.copy_and_blit.core.blit_image.* tests with
r10x6g10x6b10x6a10x6_unorm_4pack16 as the source started failing on gfx1201.
Override the mapping to PIPE_FORMAT_NONE so RADV reports zero format features,
matching the behavior prior to the new pipe format being added. Proper support
can be restored once VK_EXT_rgba10x6_formats is implemented.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40653>
