Instead of calling choose_tiling once per LOD, we now call it once at
the top and then simply clamp at every LOD like the hardware does. This
means all heuristic decisions get made up-front and the mip level walk
simply emulates the hardware.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26719>
All these vfuncs funnel down to either stubs or the xe_vm_bind_op()
function. By returning int we're shifting VkResult generation to the
callers, which are simply not doing the correct job. If they get
VkResult they can simply throw the errors up the stack without having
to erroneously try to figure out what really happened.
Today the callers are returning either VK_ERROR_UNKNOWN or
VK_ERROR_OUT_OF_DEVICE_MEMORY, but after the patch we're returning
either VK_ERROR_OUT_OF_HOST_MEMORY or VK_ERROR_DEVICE_LOST.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27926>
The bind_timeline is used to guarantee that non-sparse objects will
be bound when batches use them (although any batch will wait on the
most recent bind, even if that's not necessary). For sparse binding
resources, it's up to the user to guarantee synchronization: do not
force every single batch buffer to wait on the latest sparse binding
operation, as that adds unnecessary synchronization points.
v2: Document how each of the vfuncs interacts with bind_timeline
(José).
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27926>
Batches must be ignored if batch count is zero, so all batch inspections
have to be gated behind batch count. For memcpy, it's UB if either src
or dst is NULL even when size is zero.
Side note:
- For original commit, this fixes just the memcpy UB
- For current codes, this fixes to not skip ffb batch prepare
Fixes: 493a3b5cda ("venus: refactor batch submission fixup")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28071>
Adds a driver workaround for IHVs actually supporting rate control
reconfiguration but not reporting it in the DX12 driver support flags,
and later having crashes/hangs in the driver when the rate control
reconfiguration happens using the fallback method that includes re-creating
the encoder state and encoder heap objects upon new rate control params
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28075>
Blitter and video engines don't support PIPE_CONTROL and
3DSTATE_BINDING_TABLE_POOL_ALLOC.
I'm not 100% sure if something else should be called instead but this
is doing the same as cmd_buffer_emit_state_base_address() and this
fixes the test that was crashing in
unreachable("Trying to emit unsupported PIPE_CONTROL command.");
Fixes: dEQP-VK.pipeline.monolithic.timestamp.misc_tests.two_cmd_buffers_secondary_transfer_queue_with_availability_bit
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28053>
These 2 compute code paths were checking for
anv_cmd_buffer_is_render_queue() before calling
flush_pipeline_select_gpgpu() causing cmd_buffer->state.current_pipeline
to never to be set to GPGPU, trigerring
assert(cmd_buffer->state.current_pipeline == GPGPU) when running in
the compute engine.
So here just dropping the anv_cmd_buffer_is_render_queue() check.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28053>
Add RMV support for Turnip. The internal RMV layer is added and integrated
into the VkDevice entrypoint dispatch tables. As elsewhere, memory tracing
is put into action when enabled through the MESA_VK_TRACE environment
variable.
Similar to other implementations of RMV support in Mesa, tracing points are
added across Turnip to report on different types of RMV events, calling
into tu_rmv logging functions to emit the relevant RMV token data.
TU_BO_ALLOC_INTERNAL_RESOURCE allocation flag is added. When used, in RMV
output such an allocation will be associated with an internal resource
of the VK_RMV_RESOURCE_TYPE_MISC_INTERNAL type.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27631>
Add the vk_rmv_misc_internal_description struct and list the misc_internal
member of that type in the vk_rmv_resource_create_token union, allowing
logging of different internal resources in RMV dumps.
The vk_rmv_common.h header also has the C-linkage block added in order to
enable its inclusion in C++ files.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27631>
Faith Ekstrand