AMDGPU VCE 1: some info needed

Alexandre Demers alexandre.f.demers at gmail.com
Fri Jan 8 23:37:51 UTC 2021 

On Fri, 2021-01-08 at 15:00 -0500, Alex Deucher wrote:
> On Fri, Jan 8, 2021 at 2:37 PM Alexandre Demers
> <alexandre.f.demers at gmail.com> wrote:
> > 
> > 
> > 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.
> > 
> 
> VCE1 is configured pretty much the same as VCE2.  It looks like
> radeon
> never programmed the BAR register, but you should in amdgpu.  Your
> best bet would probably be to start with the vce_v2 code in amdgpu
> and
> copy it to a new vce_v1 file and then start from there.
> 
> Alex
> 
Thanks for the cue, VCE 2 (and VCE 3 in some part to validate) has been
a part of my "inspiration", that's the feeling I had. However, you tell
me this enforce the feeling I had about it.

Hopefully, my Holidays work will come to fruition soon.

Alexandre
> 
> > > > 
> > > > > 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
> >

More information about the amd-gfx mailing list