H.265/HEVC Main 10 Decode Support Added To Radeon UVD Code

[bug77]

So this is for RadeonSI? I thought AMFGPU was the big thing now. I can barely track names for AMD drivers, telling which one does what is pretty much impossible for me.

[juno]

So this is for RadeonSI? I thought AMFGPU was the big thing now. I can barely track names for AMD drivers, telling which one does what is pretty much impossible for me.

amdgpu is the kernel driver, delivering hardware support all the other components build onto. radeonsi is for 3D (OpenGL).

radeonsi is not to be confused with radeon. radeon is the 'predecessor' of amdgpu

[Ansla]

of course, intel skylake supports 8bit vp9 hardware decoding, i think nvidia does too. Kaby lake will support 10bit h265 and 10bit vp9. Expect pascal and polaris to support 10bit for both of these too.

Unfortunately, it looks like Polaris will not get any VP9 support, even 8bit. Do you have any source that says otherwise?

[Serafean]

So this is for RadeonSI? I thought AMFGPU was the big thing now. I can barely track names for AMD drivers, telling which one does what is pretty much impossible for me.

You need to layer it out.
There are 3 layers : Kernel(modesetting et al), mesa (3D) , DDX (Xorg).

kernel : radeon, amdgpu

Mesa : r200, r300g, r600g, radeonsi

DDX : radeon,amdgpu,glamor/modesetting (maybe more, didn't search)

All info taken from here : http://xorg.freedesktop.org/wiki/RadeonFeature/
The separation is pretty clear IMO.

S.

[bug77]

amdgpu is the kernel driver, delivering hardware support all the other components build onto. radeonsi is for 3D (OpenGL).

radeonsi is not to be confused with radeon. radeon is the 'predecessor' of amdgpu

Hence the unambiguous naming
But thanks for the explanation.

[bug77]

You need to layer it out.
There are 3 layers : Kernel(modesetting et al), mesa (3D) , DDX (Xorg).

kernel : radeon, amdgpu

Mesa : r200, r300g, r600g, radeonsi

DDX : radeon,amdgpu,glamor/modesetting (maybe more, didn't search)

All info taken from here : http://xorg.freedesktop.org/wiki/RadeonFeature/
The separation is pretty clear IMO.

S.

Imo it's not that clear when you have "radeon" and "amdgpu" listed both at kernel and at DDX level.

[bridgman]

Imo it's not that clear when you have "radeon" and "amdgpu" listed both at kernel and at DDX level.

... and Mesa, at least for radeon

Tweaking Serafean's list a bit... AFAIK the "radeon" classic Mesa driver is still in use for R100/RV200/RN50 and related parts.

There are 3 layers : Kernel(modesetting et al), mesa (3D) , DDX (Xorg).

kernel : radeon, amdgpu

Mesa : radeon, r200, r300g, r600g, radeonsi

DDX : radeon,amdgpu,glamor/modesetting (maybe more, didn't search)

https://cgit.freedesktop.org/mesa/me...ers/dri/radeon

There is also the "AMDGPU" back end for LLVM, but let's not go there

It's simple if you add a qualifier, so eg you're talking about the radeon kernel driver or the radeon Mesa driver or the radeon X driver.

I greyed out "glamor" since it is an acceleration method like EXA (with a support library so it can be used with multiple X drivers), not an X driver in its own right.

[bug77]

... and Mesa, at least for radeon

Tweaking Serafean's list a bit... AFAIK the "radeon" classic Mesa driver is still in use for R100/RV200/RN50 and related parts.



https://cgit.freedesktop.org/mesa/me...ers/dri/radeon

There is also the "AMDGPU" back end for LLVM, but let's not go there

It's simple if you add a qualifier, so eg you're talking about the radeon kernel driver or the radeon Mesa driver or the radeon X driver.

I greyed out "glamor" since it is an acceleration method like EXA (with a support library so it can be used with multiple X drivers), not an X driver in its own right.

If a driver is not isolated at a specific layer, but at the same time it's not a driver that encompasses all layer, it still looks like Frankenstein's work to me. There's logic in there, no doubt about that, but it's the kind of logic that confuses whoever doesn't have some context already.

[juno]

@bridgman: can you tell if this is supposed to be UVD 6.1 or UVD 7?

[Serafean]

If a driver is not isolated at a specific layer, but at the same time it's not a driver that encompasses all layer, it still looks like Frankenstein's work to me. There's logic in there, no doubt about that, but it's the kind of logic that confuses whoever doesn't have some context already.

Yeah, it's kind of like looking at a shell script with stuff being piped/redirected to somewhere else.
Or mixing/matching different versions of hardware blocks (UVD/TrueAudio/Display Hardware/Renderer) together.
Usually when one starts talking about drivers and their capabilities, one does want context...

S.