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