mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2025-12-31 14:10:09 +01:00
radv/video: restrict the number of IBs on video related queues.
The hardware gets given a session context from userspace in each submission, but if the session context changes the hardware wants a FENCE to be emitted to know it can give up the current session. IF a test submits interleaved session ctx access and uses a single vulkan submit the hardware crashes, unless each IB is submitted in a separate submission so the fence can be sent. In theory it could be possible to construct a single command buffer to trigger this so I do think the hardware should be smarter here. Should this be fixed in the kernel to always emit a fence between IBs? Fixes: dEQP-VK.video.decode.h264_interleaved Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23641>
This commit is contained in:
parent
0535948535
commit
13df91d7d7
1 changed files with 12 additions and 0 deletions
|
|
@ -45,6 +45,18 @@ do_winsys_init(struct radv_amdgpu_winsys *ws, int fd)
|
|||
if (!ac_query_gpu_info(fd, ws->dev, &ws->info))
|
||||
return false;
|
||||
|
||||
/*
|
||||
* Override the max submits on video queues.
|
||||
* If you submit multiple session contexts in the same IB sequence the
|
||||
* hardware gets upset as it expects a kernel fence to be emitted to reset
|
||||
* the session context in the hardware.
|
||||
* Avoid this problem by never submitted more than one IB at a time.
|
||||
* This possibly should be fixed in the kernel, and if it is this can be
|
||||
* resolved.
|
||||
*/
|
||||
for (enum amd_ip_type ip_type = AMD_IP_UVD; ip_type <= AMD_IP_VCN_ENC; ip_type++)
|
||||
ws->info.max_submitted_ibs[ip_type] = 1;
|
||||
|
||||
if (!ac_query_pci_bus_info(fd, &ws->info))
|
||||
return false;
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue