Re: [PATCH 0/2] drm/radeon: fix VCE1 encoding on SI by handling the VCE interrupt

["Christian König" <christian.koenig@amd.com>]

[Adding Timur on CC]

On 10/21/26 13:41, Matheus Tagliari wrote:
> Hardware H.264 encoding with the VCE block on SI GPUs (radeon driver)
> hangs the GPU after a few dozen frames.  I hit it with the KDE Plasma
> RDP server, which encodes through VAAPI, and reproduced it with a
> plain "ffmpeg -vaapi_device ... -c:v h264_vaapi" test on a Radeon HD
> 8870M (Cape Verde).
> 
> The VCE1 code never enables the VCE trap interrupt and the SI (and
> Trinity) interrupt handlers do not process it, unlike the CIK code and
> amdgpu.  Patch 1 adds the handlers, patch 2 enables the interrupt.

Oh, I do remember that I intentionally never enabled interrupts for VCE on radeon. But I honestly absolutely doesn't remember why (that was ~12-13 years ago!).

Timur hammered out most (all?) of the UVD/VCE bugs on SI, CIK and partially Polaris hardware as well for amdgpu and we are strongly considering just dropping SI/CIK support for radeon.

The fence handling on radeon should work completely without interrupts since those have been rather flaky on really old HW.

So no idea why that actually crashes for you if the interrupt is not enabled, my educated guess is that enabling interrupts actually doesn't fix the crash but makes it less likely because of timing change.

Would it be possible to just switch over to amdgpu instead? Or is there any support still missing there?

Regards,
Christian.

> 
> Results on Debian 6.12.113 (see patch 2 for numbers): hang before,
> none after, and 34 fps instead of ~4 fps for the workaround that avoids
> the hang.  The KDE RDP server (KRDP) itself, driven by a local FreeRDP
> client, now encodes on the VCE ring for several minutes (about 40
> fences per second on ring 6 in the radeon_fence_emit tracepoint) with a
> clean kernel log.
> 
> Two caveats:
> 
>  - I have not worked out why the missing interrupt turns into ring
>    lockups instead of only added latency.  What I know is that the
>    hang needs the VCE ring to wait on a hardware semaphore (disabling
>    only the waiting side, or both sides, of radeon_vce_semaphore_emit()
>    avoids it) and that handling the interrupt makes it go away with
>    the semaphores left enabled.  If someone knows why, I would be glad
>    to improve the commit message.
>  - The Trinity/Richland change is compile tested only.
> 
> The series was developed and tested on Debian's 6.12.113 with the
> radeon module built out of tree.  It applies cleanly on drm-next
> (fad06cf), where drivers/gpu/drm/radeon builds without warnings (W=1,
> allmodconfig) both after patch 1 and with the whole series.
> 
> Matheus Tagliari (2):
>   drm/radeon: process the VCE interrupt on SI and Trinity
>   drm/radeon/vce1: enable the VCE trap interrupt
> 
>  drivers/gpu/drm/radeon/evergreen.c | 14 ++++++++++++++
>  drivers/gpu/drm/radeon/si.c        | 14 ++++++++++++++
>  drivers/gpu/drm/radeon/sid.h       |  2 ++
>  drivers/gpu/drm/radeon/vce_v1_0.c  |  4 ++++
>  4 files changed, 34 insertions(+)
> 
> 
> base-commit: fad06cfaf385787b9ffa2f73f049d42dbe1de57f
> --
> 2.47.3
>