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

[phoronix]

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

With the experimental AMDGPU DRM driver's support for GCN 1.0 "Southern Islands" and GCN 1.1 "Sea Islands" graphics processors as an alternative to the default Radeon DRM driver, one of the disadvantages of that experimental kernel driver is losing out on UVD video decoding. But a port is in the works...

http://www.phoronix.com/scan.php?page=news_item&px=GCN-1.0-1.1-UVD-AMDGPU-RFC

[darkbasic]

I hope he will succeed.

[starshipeleven]

I hope he will succeed.

Who doesn't?

[agd5f]

You shouldn't need new firmware. You can just add a header to the existing firmware. It's fully documented in the code. Or just use the firmware without the header so it can continue to be shared with radeon.

[starshipeleven]

You shouldn't need new firmware. You can just add a header to the existing firmware. It's fully documented in the code. Or just use the firmware without the header so it can continue to be shared with radeon.

it's better to post in the mailing list there, so he will see this.

[DanL]

it's better to post in the mailing list there, so he will see this.

Trevor already knows he can copy the header. Read his message. He considered that a "new" file, whereas agd5f does not. Semantics...

EDIT: Nvm the following part. I misunderstood.

The point is that it would be nice if AMD modified the relevant blobs in the linux-firmware repo to include the header, because changing a blob file looks more trustworthy coming from AMD rather than obtaining the file off random hacker's Google Drive. I'm guessing AMD would do this eventually anyway, once their employee(s) (Christian Koenig probably) started working on it.

[starshipeleven]

The point is that it would be nice if AMD modified the relevant blobs in the linux-firmware repo to include the header, because changing a blob file looks more trustworthy coming from AMD rather than obtaining the file off random hacker's Google Drive.

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.

[DanL]

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.

Yeah, but who the heck wants to do that?

[AndyChow]

I don't even get the point of things like UVD. It never works and you're better off setting to software decode. IMO they should remove it and save themselves the mm². Or replace it with a quicksync equivalent. And not VCE, VCE isn't even faster than CPU encoding, and terrible quality.

Maybe I'm missing something.

[Peter Fodrek]

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