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

[bug77]

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.

Neah, I'm talking about this:

kernel : radeon, amdgpu

Mesa : radeon, r200, r300g, r600g, radeonsi

DDX : radeon,amdgpu,glamor/modesetting

How does one read this? Can I have DDX.AMDGPU running on top of Mesa.r300g on top of kernel.radeon? I honestly have no clue.

[bridgman]

How does one read this? Can I have DDX.AMDGPU running on top of Mesa.r300g on top of kernel.radeon? I honestly have no clue.

The radeon and amdgpu kernel drivers have different driver-specific IOCTLs, but AFAIK they both implement the standard IOCTLs used for modesetting (not sure about status of atomic vs. coal-fired modesetting though).... so modesetting should be able to run over either because it doesn't use driver-specific IOCTLs while amdgpu and radeon need to work with their corresponding kernel drivers.

I suppose that in theory a DDX using only glamor for acceleration might be able to run over "the other kernel driver" (eg radeon ddx over amdgpu kernel driver and vice versa) but I doubt it's that simple. The reason for having a DDX other than modesetting these days is to be able to implement functionality that requires driver-specific IOCTLs (or code/knowledge I guess) so even if it works today it probably wouldn't work in the future.

The radeonsi driver (strictly speaking the radeon Mesa winsys driver I guess, we should add that to the list below the Mesa pipe drivers) contains code paths to let it work over radeon or amdgpu, at least for CI.

[juno]

edit: bridgman ninja-posted and might have the better explanation

[bridgman]

The mesa/gallium (radeonsi) and ddx drivers build upon the kernel/drm driver
....

Yeah, we should add the libdrm bits to the list as well as winsys and llvm back ends. Just so it doesn't all seem too simple

[bug77]

The radeon and amdgpu kernel drivers have different driver-specific IOCTLs, but AFAIK they both implement the standard IOCTLs used for modesetting (not sure about status of atomic vs. coal-fired modesetting though).... so modesetting should be able to run over either because it doesn't use driver-specific IOCTLs while amdgpu and radeon need to work with their corresponding kernel drivers.

I suppose that in theory a DDX using only glamor for acceleration might be able to run over "the other kernel driver" (eg radeon ddx over amdgpu kernel driver and vice versa) but I doubt it's that simple. The reason for having a DDX other than modesetting these days is to be able to implement functionality that requires driver-specific IOCTLs (or code/knowledge I guess) so even if it works today it probably wouldn't work in the future.

The radeonsi driver (strictly speaking the radeon Mesa winsys driver I guess, we should add that to the list below the Mesa pipe drivers) contains code paths to let it work over radeon or amdgpu, at least for CI.

I rest my case. Shall we get back on topic now?

[SystemCrasher]

bridgman, btw, would AMD implement VP9 HW decoding? Who gives a fuck about H.265, if whole youtube HQ content is VP9 at their best resolutions/quality? At 2K/4K it could get quite taxing on CPU and these days I can't imagine HTPC-like use cases without youtube support.

I.e. I'm not really sure where I'm supposed to get H.265 content. But there is plenty of content in VP9 due to youtube. And it could be also nice to cooperate with browser vendors to improve decoding. Sure, some strange guy would ask about DVB-T. But hundreds of millions of users are better with just viweing youtube and I can admit such a basic use case have got a long way to go. Especially on Linux, where video playback in browsers isn't something to be proud of at all.

[bridgman]

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.

I rest my case. Shall we get back on topic now?

Um... sure

bridgman, btw, would AMD implement VP9 HW decoding? Who gives a fuck about H.265, if whole youtube HQ content is VP9 at their best resolutions/quality? At 2K/4K it could get quite taxing on CPU and these days I can't imagine HTPC-like use cases without youtube support.

That would be one of those "unreleased hardware" things that we don't talk about, sorry.

[Nille_kungen]

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

Let us not forget that Catalyst is now Radeon Software, this is why i still use Catalyst name instead of Radeon Software.
Radeonsi is for GCN cards.
This shows cards supported by the radeon kernel driver and the mesa 3D driver https://wiki.gentoo.org/wiki/Radeon#Feature_support i do think that http://xorg.freedesktop.org/wiki/Rad...ture/#index5h2 should have the mesa 3D driver like that table in the gentoo wiki.

[drSeehas]

So Stoney ... Bristol Ridge. ...

What is the difference between FP4 Stoney Ridge and FP4 Bristol Ridge?

[juno]

What is the difference between FP4 Stoney Ridge and FP4 Bristol Ridge?

Stoney < Bristol.
Stoney is low-end, replacing Carrizo-L, which is based on the tiny Puma+ Cores, Bristol is replacing Carrizo.
IIRC, Stoney has 1 "bulldozerish" module (2 integer cores, 1 FPU) and probably <= 4 GCN CUs (Compute Units). Carrizo has 2 modules and <= 8 CUs.
So stoney will be targeting low-end laptops, embedded devices and maybe also tablets (I don't expect that, actually, as the eligible Mullins was not found in any, too).
Bristol Ridge on the other hand should be targeting mid-range laptops, and of course the desktop on AM4, too.