AMDGPU VCE 1: some info needed

Fri Jan 8 19:37:52 UTC 2021

On Fri, 2021-01-08 at 10:28 -0500, Alex Deucher wrote:
> On Fri, Jan 8, 2021 at 3:11 AM Christian König
> <ckoenig.leichtzumerken at gmail.com> wrote:
> > 
> > Hi Alexandre,
> > 
> > Am 08.01.21 um 05:20 schrieb Alexandre Demers:
> > > Hi there,
> > > 
> > > Some of you may remember I was working on porting VCE 1 from
> > > Radeon to
> > > AMDGPU a few years ago... about 3 and a half years. I hadn't had
> > > time
> > > to work on it until last Holidays. But why do I persist in this
> > > work?
> > > Because GCN 1st gen was still used in some GPU produced 4 years
> > > ago
> > > (Radeon 520 and just before R5 and R7 in the entry level).
> > 
> > Yes and that is really valued.
> > 
> > If we can get that working and and it is feature equivalent to
> > radeon
> > I'm perfectly fine to merge this.
> > 
> > > I'm pretty happy with where the code is sitting now, however I
> > > have
> > > some questions.
> > > 
> > > 1- should the firmware be validated like it was under Radeon and
> > > as it
> > > is done for the newly ported UVD 3.1 code? This would mean having
> > > to
> > > work with keyselect, isn't it?
> > 
> > No, that should only be necessary for UVD.
> > 
> > > 2- last time I worked on VCE 1.0, Christian was saying that it
> > > was
> > > possible a new VCE firmware could be provided for AMDGPU. Then,
> > > it
> > > wasn't that clear, GCN 1.0 (SI) being in trouble and it was
> > > considered
> > > to strip it from AMDGPU. And a few months ago, UVD and DC were
> > > added
> > > for SI to AMDGPU and a new UVD firmware was released (yeah!). So,
> > > is
> > > it possible to have a new VCE firmware? I produced an "updated"
> > > tahiti
> > > VCE file where a header is added (script available on my account
> > > on
> > > GitHub). Still, if this can be useful, I'd prefer an official
> > > firmware.
> > 
> > Leo and I can push once more on this, but no guarantee that this
> > will
> > ever see the day of light.
> > 
> > It was a really long and taxing process of getting UVD for SI out
> > of the
> > door.

Well, if this doesn't block porting the code, let's just leave things
as they are for now.

> > 
> > > 3- is there any documentation about VCE 1.0 that would help me
> > > complete this work?
> > 
> > Unfortunately not, we only have what was exposed with the initial
> > code drop.
> > 
> > > 3.1- Some variables that were previously defined are not
> > > available
> > > under sid.c, vce_v1_0_d.h, vce_v1_0_sh_mask.h and others. Since
> > > the
> > > new values (mostly in the range of 0x8xxx) are completely
> > > different
> > > from the ones defined under Radeon (in the range of 0x2xxxx), I'd
> > > like
> > > to be sure to use the good ones. I would assume the masks and
> > > shifts
> > > are still valid though.
> > 
> > Do you have an example of what you need?
> 
> Note that radeon uses byte aligned register headers and amdgpu uses
> dword aligned registers headers, so you'll need to shift the
> definitions appropriately if you need to add any of the offsets to
> amdgpu.  I think vce_1_0 headers should be fine to use as is in
> amdgpu.
> 
> Alex
> 

Ah bummer! That's why. OK, I'll keep that in mind revising my work
then.

> > 
> > > 3.2- Some statuses are undefined, sometimes magic values appear
> > > here
> > > and there without being ever defined or documented (status 0x337f
> > > anyone?), even under CIK or they don't seem to be easily portable
> > > from
> > > other VCE versions. Having a name for a value is really helpful
> > > without an official documentation, when the code is supposed to
> > > be
> > > self-documented. I've been able to identify some of them by
> > > looking at
> > > variables used under Radeon or under AMDGPU's UVD 3.1.
> > > Interestingly,
> > > some variables were previously defined under Radeon, but were
> > > left
> > > aside in AMDGPU...
> > > 
> > > 3.3- Being able to know how to properly set/reset which part, in
> > > what
> > > order, etc.
> > 
> > Sorry, I don't think we can help with documentation here. What I
> > can do
> > is to test your stuff on SI hardware if you get stuck with
> > something and
> > report back what might be the issue.

If I get this working on my R9 280X, I'll gladly let you test it on
other hardware.

> > 
> > > 4- Any input about 40 bit address limitation on VCE 1.0 and how
> > > to
> > > handle it if it applies?
> > 
> > You mean the 24 bit address limitation of UVD, don't you? That
> > should
> > not apply to VCE in general.

Well, a bit of this, a bit of that. I indeed see that UVD has an
address limitation. However, VCE 2 and 3 call on 40bit BAR which was
not done the same under Radeon (not that I've realized). But with
Alex's previous comment and this in mind, I'll revisit this part.

> > 
> > > 5- Any chance to have some code reviewed even if it still doesn't
> > > work
> > > if I send it on this list?
> > 
> > Let's try to get it working first.
Ok. I'll come back if I need more info.

> > 
> > > 6- I have some patches on the side to help document the code and
> > > define variables (even for Radeon), a few typos fixed, etc.
> > > Should I
> > > send them on this list?
> > 
> > For radeon we are more or less in a maintenance mode. If it just
> > adds
> > comments then we can certainly add it, but if you have any
> > functional
> > change I would be a bit hesitated.
No, aesthetic only. ;) I'll send them at some point then.

Thanks to both of you.
Alexandre

> > 
> > Regards,
> > Christian.
> > 
> > > 
> > > Cheers
> > > 
> > > Alexandre Demers
> > > _______________________________________________
> > > amd-gfx mailing list
> > > amd-gfx at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > 
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx