Since e94cb92cb0 ("anv: use internal surface state on Gfx12.5+ to
access descriptor buffers") we're only using the 32bit_index_offset
address format for loads from descriptor memory.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41047>
I ran into this case where genX(cmd_buffer_emit_bt_pool_base_address)
was returning immediately because it considered an RCS engine
emulating a compute queue as neither a render nor a compute queue.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41047>
Probably worked because we could always reach to things through the
binding table and the index was the same.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41047>
For some reason the android builders started noticing...
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41047>
The Vulkan spec states that if VK_KHR_shader_clock is supported,
shaderSubgroupClock is a required feature. So let's not enable that
extension unless we can...
Fixes: e9c2c32409 ("panvk: enable VK_KHR_shader_clock")
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Ashley Smith <ashley.smith@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40944>
The Vulkan spec states that if VK_ARM_shader_core_builtins is supported,
shaderCoreBuiltins is a required feature. So let's not enable that
extension unless we can...
Fixes: dff1d91c64 ("panvk: Enable VK_ARM_shader_core_builtins")
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40944>
LLVMpipe is the only driver that actually has supported the instructions
that this cap reports about. But TGSI is a dying IR, and this helps very
little; the compiler back-end will optimize this away anways.
So let's drop it to reduce complexity.
Acked-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40993>
These instructions were never supported on Iris, as it never supported
TGSI. This didn't lead to any issues because tgsi_to_nir normalized the
result. This mistake got carried forward when creating crocus as well.
Let's just stop reporting it; it doesn't do anything useful.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40993>
This hasn't been supported since the TGSI envvar was ripped out. When
converted to NIR, we don't see these instructions at all.
Fixes: c3cbe610df ("nouveau: Delete the NV50_PROG_USE_TGSI env var.")
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40993>
Remove the TU_DEBUG_FLUSHALL option that was force-enabled for a8xx chips.
The problematic CTS cases that required it were failing due to indirect
draw commands sourcing draw data from buffers whose content was prepared
by compute tasks.
Up until a8xx, firmware was managing an implicit wait before any indirect
draw parameters were read, with a delayed CP_WAIT_FOR_ME emitted only when
necessary or on devices enabling indirect_draw_wfm_quirk due to bugged
firmware. That implicit wait is gone on a8xx, so CP_WAIT_FOR_ME should be
emitted immediately, which also matches behavior of the proprietary driver.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40550>
The HW supports larger buffer-sizes on v11 and later, so let's bump
this up.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40999>
The HW supports larger resource-sizes on v11 and later, so let's bump
this up. But since we have a knob to limit the usable VA space, we need
to take that into account here as well.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40999>
