Work-In-Progress Porting Of GCN 1.0/1.1 UVD To AMDGPU DRM Driver

[PuckPoltergeist]

Another use case is a media PC, mini PC or cheap laptop where the CPU is a low-frequency Excavator that just can't handle it on CPU alone.

Even Jaguar-based systems will do this. Excavator really doesn't have a problem with this.

[Peter Fodrek]

Why? How does that relate?

Because there is lot of features that does not work with AMDGPU without DAL/DC including

AMDGPU display code, but given the massive undertaking, it's a lot of work to get done in a short amount of time when they are already stretched for resources. This is also a setback to anyone hoping to use the mainline AMDGPU kernel driver with HDMI/DP audio, FreeSync, HDMI 2.0, atomic mode-setting, DP MST, and other modern display features.

https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-DRM-No

[geearf]

Because there is lot of features that does not work with AMDGPU without DAL/DC including

AMDGPU display code, but given the massive undertaking, it's a lot of work to get done in a short amount of time when they are already stretched for resources. This is also a setback to anyone hoping to use the mainline AMDGPU kernel driver with HDMI/DP audio, FreeSync, HDMI 2.0, atomic mode-setting, DP MST, and other modern display features.

https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-DRM-No

Right, but you wrote that this work was "One more resason to merge DAL/DC/Display Code as soon as possible".
I don't see the relation.

[darkbasic]

It doesn't relate to DAL/DC in any way.

[Peter Fodrek]

Right, but you wrote that this work was "One more resason to merge DAL/DC/Display Code as soon as possible".
I don't see the relation.

I think It is wanted to switch all GCN based GPU to AMDGPU and support of listed features in AMDGPU depends on Display code and it blocks use only AMDGPU for all GCN GPUs but I may be false

[timofonic]

Heh it's a header, a few kbytes at most at the beginning that contain some info read by the driver itself for loading the blob. As long as you know how big it is you can dd it off and checksum the binary with the others we have.

Or ship a opensource tool that does the header change on known-good firmware files coming from AMD so distros can automatically deal with this.

Really, a header is the binary equivalent of a sticker with a name, nothing more.

Or get rid of binary blobs (AtomBios?) and release proper full specs to deal directly with the GPU and remove crappy layers. Hell, PS4 hackers got hidden documentation in a website for the GPU (PS4 uses a modified older generation AMD GPU in SoC) that's a lot better than the official one!

One more resason to merge DAL/DC/Display Code as soon as possible

Duke Nukem Forever? Hahaha.

They should remove another crappy layer before: AtomBios.

Try dropping CPU use from 50% to 3-5%; that's 20 to 40W saving. Another use case is a media PC, mini PC or cheap laptop where the CPU is a low-frequency Excavator that just can't handle it on CPU alone.

Does UVD really works? Why not replace it by a totally reprogrammable FPGA-like section to build codecs for it instead having hardcoded ones? If you use newer codecs or use certain unimplemented features, UVD will not be able to deal with it.

Because there is lot of features that does not work with AMDGPU without DAL/DC including

AMDGPU display code, but given the massive undertaking, it's a lot of work to get done in a short amount of time when they are already stretched for resources. This is also a setback to anyone hoping to use the mainline AMDGPU kernel driver with HDMI/DP audio, FreeSync, HDMI 2.0, atomic mode-setting, DP MST, and other modern display features.
https://www.phoronix.com/scan.php?pa...DGPU-DC-DRM-No

AMDGPU sucks until they solve that. And it will still suck until AMD releases full specs and don't obfuscate their drivers with magic numbers and many other crap (PS4 hackers got amused at how their code sucks because it looks quite obfuscated). They must kill AtomBios, really.

[geearf]

I think It is wanted to switch all GCN based GPU to AMDGPU and support of listed features in AMDGPU depends on Display code and it blocks use only AMDGPU for all GCN GPUs but I may be false

No, SI won't use it. I'm not sure about CIK but I doubt it. So it's not a blocker in this case, it actually doesn't matter at all for this.

[nanonyme]

No, SI won't use it. I'm not sure about CIK but I doubt it. So it's not a blocker in this case, it actually doesn't matter at all for this.

I thought moving SI over to AMDGPU was a prerequisite for getting OSS Vulkan on those chips

[geearf]

I thought moving SI over to AMDGPU was a prerequisite for getting OSS Vulkan on those chips

Yes it is, display code though is not

[starshipeleven]

Or get rid of binary blobs (AtomBios?) and release proper full specs to deal directly with the GPU and remove crappy layers. Hell, PS4 hackers got hidden documentation in a website for the GPU (PS4 uses a modified older generation AMD GPU in SoC) that's a lot better than the official one!

And this has any bearing with what I was talking about... because?