AMDGPU VCE 1: some info needed

AMDGPU VCE 1: some info needed

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

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?

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.

3- is there any documentation about VCE 1.0 that would help me
complete this work?
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.

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.

4- Any input about 40 bit address limitation on VCE 1.0 and how to
handle it if it applies?

5- Any chance to have some code reviewed even if it still doesn't work
if I send it on this list?

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?

Cheers

Alexandre Demers
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: AMDGPU VCE 1: some info needed

[Christian König]

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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: AMDGPU VCE 1: some info needed

[Alex Deucher]

On Fri, Jan 8, 2021 at 3:11 AM Christian König
<ckoenig.leichtzumerken@gmail.com> 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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: AMDGPU VCE 1: some info needed

[Alexandre Demers]

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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: AMDGPU VCE 1: some info needed

[Alex Deucher]

On Fri, Jan 8, 2021 at 2:37 PM Alexandre Demers
<alexandre.f.demers@gmail.com> 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@gmail.com> 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@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > >
> > > _______________________________________________
> > > amd-gfx mailing list
> > > amd-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: AMDGPU VCE 1: some info needed

[Alexandre Demers]

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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx