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