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

[Matheus Tagliari <mptagliari@gmail.com>]

On Wed, Oct 21, 2026 at 04:10:04PM +0200, Christian König wrote:
> 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?

Thanks for taking a look.

On the interrupt: I agree I have not shown why the hang happens, and a
timing change is entirely possible.  What I can say is limited to this:

 - stock radeon: every encode hung within about 100 frames (many runs);
 - with the VCE ring semaphores disabled: no hang, but fences are only
   noticed by the wait timeout, about 4 fps (~256 ms per frame);
 - with the interrupt enabled and handled, semaphores left on: no hang
   in roughly ten minutes of total encode time (up to 1080p, plus
   several minutes of KDE's RDP server).

That is correlation, not a root cause.  If it helps I can test enabling
VCE_SYS_INT_EN without processing the fences from the handler, and run a
long soak test with two concurrent encodes.

One difference that may be relevant: on CIK radeon does enable and
process the VCE interrupt (vce_v2_0_resume() sets VCE_SYS_INT_EN and
cik_irq_process() handles src_id 167).  Only VCE1 (SI and Trinity)
never did.

On amdgpu: it works for me, I found nothing missing for this use.  I
tested it on 7.2.9 and on Debian's 6.12.113 with the amdgpu VCE1 series
backported: h264_vaapi encodes up to 1080p with DPM and runtime PM
enabled, no hangs.

The reason I looked at radeon at all is the distribution situation.
Debian 13 stable ships 6.12, where SI is driven by radeon by default
and amdgpu has no VCE1 support (that needs a newer kernel, which Debian
only offers through backports).  So anyone on the stable kernel who
uses VAAPI encoding on an SI card, here through KDE's RDP server, ends
up with a wedged GPU.

Since you are considering dropping SI/CIK from radeon, I do not want to
push a change you don't want.  If radeon keeps SI for the 6.x kernels,
what would you prefer?

 a) this series;
 b) disable the VCE semaphores like uvd_v1_0 did in 013ead48a843 (works
    here, but slow);
 c) leave radeon alone and just document VCE encoding on SI with radeon
    as a known issue that amdgpu's VCE1 support in newer kernels
    supersedes (even a one-line warning pointing to amdgpu.si_support=1
    would help people on 6.x).

I am fine with any of them, and if it is (c) please feel free to ignore
the series.  A v2 of patch 2 that fixes the CIK register issue found by
the automated review is ready in case you want (a).

Regards,
Matheus