From: "Timur Kristóf" <timur.kristof@gmail.com>
To: "Matheus Tagliari" <mptagliari@gmail.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] drm/radeon: fix VCE1 encoding on SI by handling the VCE interrupt
Date: Thu, 22 Oct 2026 15:21:52 -0600 [thread overview]
Message-ID: <9yQu5OqOSQiEjRU6vUeH3Q@gmail.com> (raw)
In-Reply-To: <3c11368b-06a3-4f25-8dc3-f57596b4f627@amd.com>
On 2026. október 22., csütörtök 4:00:53 középső államokbeli zónaidő Christian
König wrote:
> 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?
Hi,
I skimmed the series and it looks OK to me, though I don't have the energy to
actually test the radeon KMD. My 20 cents say we should apply the series and
see what happens. It won't impact any users who are already using amdgpu, but
hopefully if we backport the series it will help users who are stuck on old
distros like Matheus says, or old pre-GCN APUs.
Best regards,
Timur
prev parent reply other threads:[~2026-10-22 21:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 11:41 Matheus Tagliari
2026-10-21 11:41 ` [PATCH 1/2] drm/radeon: process the VCE interrupt on SI and Trinity Matheus Tagliari
2026-10-21 11:41 ` [PATCH 2/2] drm/radeon/vce1: enable the VCE trap interrupt Matheus Tagliari
2026-10-21 14:10 ` [PATCH 0/2] drm/radeon: fix VCE1 encoding on SI by handling the VCE interrupt Christian König
2026-10-21 14:12 ` Alex Deucher
2026-10-21 15:33 ` Matheus Tagliari
2026-10-22 10:00 ` Christian König
2026-10-22 21:21 ` Timur Kristóf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9yQu5OqOSQiEjRU6vUeH3Q@gmail.com \
--to=timur.kristof@gmail.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mptagliari@gmail.com \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®