Either the rendering begins in the primary and the information is
already known, or if it begins in the secondary, non-coherent RBs
should already be flushed in EndCommandBuffer().
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41136>
This shouldn't have any effects because there is a dirty bit and
binding the same graphics pipeline doesn't trigger it.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41136>
Checking if there is a bound graphics pipeline should be enough to
reset the appropriate states. Also clear the dirty pipeline bit only
for graphics pipelines because it's not used for compute pipelines.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41136>
This is used to declare barrier dependencies for an addr range
(because no VkBuffer with DAC).
This fixes new dEQP-VK.api.device_address.misc.memory_range_barrier.
Fixes: a97c889a7b ("radv: implement VK_KHR_device_address_commands")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41198>
ac_nir_optimize_outputs() might pack user varyings into the color
built-ins. If this happens we skip adding clamping to the
components that contain the user varying.
This change also fixes a second bug where a color built-in can be
packed into a non-color slot and was no longer being clamped.
Fixes: 3777a5d7 ("radeonsi: assign param export indices before compilation")
Closes: #14443
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40594>
No intended functional change.
This prevents possible breakage due to DCE removing input loads followed
by nir_shader_gather_info updating input masks and changing the result of
ac_nir_get_io_driver_location after PS input register contents are already
determined.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41175>
Enable hardware decode/encode capabilities for VCN 5.3.0 by
configuring the supported codec list. This allows vainfo to
properly enumerate available codec capabilities.
Signed-off-by: Suresh Guttula <suresh.guttula@amd.com>
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41202>
Enable VK_KHR_performance_query on GFX11 (RDNA3 / RDNA3.5) now that the
selector tables and packet emission are in place.
Tested on Strix Halo with dEQP-VK.query_pool.performance_query.* (6 pass,
6 not-supported for the allowCommandBufferQueryCopies cases).
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41157>
GFX11 reorganizes the shader perfcounter blocks: wave counts move from
SQ to the SQG registers (still mapped as the SQ block in ac/), while
per-instruction counters move from SQ to the new SQ_WGP block.
Add GFX11-specific selector enums using the new block assignments and
branch radv_query_perfcounter_descs to select them on GFX11+. GL2C,
GL1C, and TCP selectors are unchanged between GFX10.3 and GFX11.
The "Instructions" (total count) counter is dropped on GFX11 as there
is no direct SQ_WGP equivalent for INSTS_ALL.
Selector indices verified against gpu_performance_api's
gpa_hw_counter_gfx11.cc.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41157>
Some perfcounter blocks (e.g. SQ_WGP on GFX11) define num_spm_modules
but have no select1 register array. Skip the select1 loop when the
array is NULL.
This is a prerequisite for enabling performance queries on GFX11.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41157>
Casting a negative float to uint64_t is undefined behavior. GCC 15 with
-O2 produces 0xFFFFFFFFFFFFFFFF for (uint64_t)(-32767.5f), causing snorm
clear values to be packed incorrectly (e.g. 0xFFFF instead of 0x8001 for
snorm16 -1.0). This results in wrong DCC comp-to-single clear colors and
~966 CTS snorm multisample_resolve test failures.
Fix by casting through int64_t first, which is well-defined (truncation
toward zero) and preserves the two's complement bit pattern.
Fixes: 585c25be1e ("radv: fix color conversions for normalized uint/sint formats")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41164>
The Vulkan spec says:
"After a call to vkCmdExecuteGeneratedCommandsEXT, command buffer
state will become undefined according to the tokens executed. This
table specifies the relationship between tokens used and state
invalidation."
The application must re-bind the states that are updated using DGC.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41159>
Only if DGC emits an indexed draw without providing the index buffer
as part of the tokens. This avoids emitting useless packets.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41159>
Save protected radv_queue in device->queues_protected so it can be
relased in radv_destroy_device.
Without this, device->queues[] will point to a new queues to record
the queue created according to the queueCreateInfo. When queueCreateInfo
include both protected and unprotected queue info, the device->queues[]
will be created twice and record one queue at each time. So we will lose
either protected queue or unprotected queue which created first.
Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40619>
Create encrypted fence_bo and eop_bug_bo when the radv_cmd_buffer is
created from a protected pool which is marked with flag
VK_COMMAND_POOL_CREATE_PROTECTED_BIT
Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40619>
Pass secure flag to radv_update_preamble_cs() if this queue is created
with vk flag VK_QUEUE_PROTECTED_BIT and create encrypted tess/ge ring
BOs and compute_scratch_bo according to this secure flag.
Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40619>
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>
