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