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