The assertion `assert(afence->seq_no <= *user_fence_cpu)` in
`amdgpu_fence_wait` can trigger a Mesa exit during GPU mode2 resets in
virtualized guest environments.
A GPU reset can cause the hardware to discard commands, including the
one that updates the user fence BO (`*user_fence_cpu`). This leaves
`*user_fence_cpu` with an older value, while `afence->seq_no` (from
command submission) is newer, leading to
`afence->seq_no > *user_fence_cpu` and triggering the assert.
Removing this assert prevents Mesa from exiting in this reset scenario.
No adverse side effects observed during testing. The assert appears
overly strict for hardware reset events where command completion is not
guaranteed.
Signed-off-by: Wei Zhao <wei.zhao@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34924>
Add queue id support to the user queue wait IOCTL
drm_amdgpu_userq_wait structure.
This is required to retrieve the wait user queue and maintain
the fence driver references in it so that the user queue in
the same context releases their reference to the fence drivers
at some point before queue destruction.
Otherwise, we would gather those references until we
don't have any more space left and crash.
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34493>
The existing code relies on assert to identify when a cs overlow
occurs. On builds without asserts, a cs overflow won't be detected
and it will likely lead to a hang.
Reporting a preemptively a PIPE_UNKNOWN_CONTEXT_RESET error seems
ok as the context is lost anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33288>
The userq packets are added using _pkt_begin(), _pkt_add(), _pkt_end()
functions. As of now _pkt_being() and _pkt_add() is called once. It
is not advisible to update wptr value in mqd multiple times. Hence use
next_wptr as cache in the macros and update mqd mptr before job submission
only once.
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32700>
The signal ioctl should only be called after guaranteeing that the hardware
started working on the submissions and that is only after doorbell is ringed.
Otherwise it can in theory happen that the application creates the fence and
is then interrupted before ringing the doorbell. That can result in a GPU
reset because the fence times out.
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32700>
This is required to implement virtio native-context.
In a virtualized environment, most of the functions provided
by libdrm_amdgpu will be implemented using virtio.
This allows to implement efficient virtualization, by
forwarding the kernel API to the host, instead of the GL/VK calls.
Similarly, the raw 'fd' or 'gem_handle' arguments are replaced
by opaque types. This allows to encapsulate all the needed
state in the handle, and use unmodified API between baremetal
and virtualized contexts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
This patch adds the job submission code for userq. An indirect buffer, in
short ib, can be considered a job. The job is submitted directly to the
userq ring buffer and the doorbell is rung to notify the firmware to
execute the job.
The packets that are submitted to execute the job is below,
1) fence wait multi packet for any dependency fence
2) hdp flush packs to flush host data path
3) indirect buffer packet
4) protected signal packet
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
This imports 35 libdrm_amdgpu functions into Mesa.
The following 15 functions are still in use:
amdgpu_bo_alloc
amdgpu_bo_cpu_map
amdgpu_bo_cpu_unmap
amdgpu_bo_export
amdgpu_bo_free
amdgpu_bo_import
amdgpu_create_bo_from_user_mem
amdgpu_device_deinitialize
amdgpu_device_get_fd
amdgpu_device_initialize
amdgpu_get_marketing_name
amdgpu_query_sw_info
amdgpu_va_get_start_addr
amdgpu_va_range_alloc
amdgpu_va_range_free
We can't import them because they make sure that we only use 1 VMID
per process shared by all APIs. (except the marketing name)
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32067>
This is achieved by the following steps:
#ifndef DEBUG => #if !MESA_DEBUG
defined(DEBUG) => MESA_DEBUG
#ifdef DEBUG => #if MESA_DEBUG
This is done by replace in vscode
excludes
docs,*.rs,addrlib,src/imgui,*.sh,src/intel/vulkan/grl/gpu
These are safe because those files should keep DEBUG macro is already excluded;
and not directly replace DEBUG, as we have some symbols around it.
Use debug or NDEBUG instead of DEBUG in comments when proper
This for reduce the usage of DEBUG,
so it's easier migrating to MESA_DEBUG
These are found when migrating DEBUG to MESA_DEBUG,
these are all comment update, so it's safe
Replace comment /* DEBUG */ and /* !DEBUG */ with proper /* MESA_DEBUG */ or /* !MESA_DEBUG */ manually
DEBUG || !NDEBUG -> MESA_DEBUG || !NDEBUG
!DEBUG && NDEBUG -> !(MESA_DEBUG || !NDEBUG)
Replace the DEBUG present in comment with proper new MESA_DEBUG manually
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28092>
This fixes a VCN performance regression introduced by the new BO fence
tracking mechanism.
VCN can have many queues. The current BO fence tracking mechanism only
supports 1 queue per IP, and there is an interest to use all VCN queues via
VAAPI. This introduces an alternative BO fence tracking mechanism that is
only enabled for VCN, supports unlimited parallel queues, is similar to
the previous system, can co-exist with the current queue system, and has no
negative impact on CPU overhead as long as it's only used by VCN.
Since we want an unlimited number of queues, we can't generate our own
sequence numbers for those queues. Instead, each buffer will have a new
field "alt_fence", which means an alternative fence. This fence is the last
use of that buffer on any VCN queue. If any other queue wants to use that
buffer, it has to insert alt_fence as a dependency, and replace alt_fence
with the new submitted fence, so that it's always equal to the last use.
Only VCN uses and updates alt_fence when an IB is submitted. Other IPs only
use alt_fence as a fence dependency. alt_fence is NULL when VCN isn't used,
so there is no negative impact on CPU overhead in that case.
It uses a C++ template for amdgpu_cs_submit_ib due to different BO loop
bodies between normal queues and VCN. Those loop bodies execute for every
BO, so they shouldn't have extra code for alt_fence if the queue doesn't
update it.
Acked-and-Tested-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27627>
Marek Olšák