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

[Christian König]

On 10/21/26 17:33, Matheus Tagliari wrote:
> 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).

Yeah as Alex pointed out trinity is not supported by amdgpu and never will.

On the other hand that APU was the first one with VCE and I widely remember how buggy that HW was. So it is probably a wonder that this works in the first place.

I would say we take the patch and see. If anybody starts screaming we will probably just revert it immediately.

Problem is more than I have no time at all to wrap my head around that code again. @Timur can you do me a favor and take a look?

The radeon VCE code is basically the ancestor of the amdgpu VCE code. 

Regards,
Christian.

> 
> Regards,
> Matheus