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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > > > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > > > > > > _______________________________________________ > > > > amd-gfx mailing list > > > > amd-gfx@xxxxxxxxxxxxxxxxxxxxx > > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
