Digging Deeper Into AMD's UVD Code Drop

[phoronix]

Phoronix: Digging Deeper Into AMD's UVD Code Drop

Yesterday it was exclusively announced on Phoronix that AMD was releasing open-source UVD code so that their open-source Linux graphics driver can finally benefit from GPU hardware-accelerated video playback. Here's some more details...

http://www.phoronix.com/vr.php?view=MTM0MjA

[uid313]

Great but

This is really great and makes AMD more attractive to me to!

But they need to get better at publishing changelogs, and support the latest X.Org Server releases.

It really bothers me a lot that it takes months for AMD to get a driver to support the latest X.Org Server release, every time!

It really bothers me that they are holding back progress by forcing distributions to ship old X.Org releases.

[r1348]

This is really great and makes AMD more attractive to me to!

But they need to get better at publishing changelogs, and support the latest X.Org Server releases.

It really bothers me a lot that it takes months for AMD to get a driver to support the latest X.Org Server release, every time!

It really bothers me that they are holding back progress by forcing distributions to ship old X.Org releases.

Why does it make it more attractive to you, if you're going to use the proprietary driver anyway?

[Ericg]

Why does it make it more attractive to you, if you're going to use the proprietary driver anyway?

makes them more attractive to me because I don't feel like I have to use proprietary driver now. though better pm will shift me even further

[uid313]

Why does it make it more attractive to you, if you're going to use the proprietary driver anyway?

Because I like having options.
I am currently on a Nvidia card and for a long time I've used the proprietary driver, but lately I've been using the open source driver which works great for me, and it even works for the old game I play, however for newer games it doesn't work so well. So if I were to go play some new games, I can go back to the proprietary driver.

So if I was on AMD card, I would first try go with the open source driver, but it if wasn't good, I would like the option to use the proprietary driver.

[przemoli]

This is good news for all FLOSS driver users. Its no-good news for all Catalyst users :| as apps now will double down on VDPAU (not as if Catalyst alternative was good, but..)

And we may not see Catalyst adopting VDPAU

[halfmanhalfamazing]

To blob or not to blob, that is the question

I am not afraid to admit that the totality of what has happened in the last two days is not totally 100% clear to me.

This UVD code drop, how open is open? Yesterday's announcement made it seem as if UVD is now out in the open once and for all. But here today, Michael is talking about microblobs.

Don't get me wrong, I think this is all great and I have nothing but love for what AMD has done, I'm just curious as to what these microblobs are for if UVD is now indeed open source material. Is that nothing more than the remaining Digital Rights Management garbage?

[bridgman]

Pretty much all modern hardware uses microcode to implement complex logic. Some vendors store the microcode permanently on the chip, some store most of it on-chip but include a writeable CAM for patching (eg Intel/AMD CPUs), and some store the entire microcode image in writeable RAM.

ATI/AMD GPUs fall into the last category, where the driver has to load microcode images for blocks like the memory controller state machine, the gfx command processor that reads commands from a DMA ring buffer, a few other blocks (PFP and RLC, think I'm missing one) and now the UVD block in order for the hardware to operate correctly.

Those microcode images are being described as "blobs" in the article, which is potentially confusing because "blob" is also used to describe precompiled binary code running on the CPU (eg a binary graphics driver).

All of the code running on the CPU is open source.

[Ericg]

Pretty much all modern hardware uses microcode to implement complex logic. Some vendors store the microcode permanently on the chip, some store most of it on-chip but include a writeable CAM for patching (eg Intel/AMD CPUs), and some store the entire microcode image in writeable RAM.

ATI/AMD GPUs fall into the last category, where the driver has to load microcode images for blocks like the memory controller state machine, the gfx command processor that reads commands from a DMA ring buffer, a few other blocks (PFP and RLC, think I'm missing one) and now the UVD block in order for the hardware to operate correctly.

Those microcode images are being described as "blobs" in the article, which is potentially confusing because "blob" is also used to describe precompiled binary code running on the CPU (eg a binary graphics driver).

All of the code running on the CPU is open source.

Hold up Bridgman, just to clarify. Is the firmware that is loaded open source or no? Michael made a comment about it "At least working with future kernels..." which made it sound like the firmware is closed source but the accessor functions that control it and direct it are open source and can therefore be patched and changed as the kernel goes.

Was there really any way for the open source developers to code for UVD and try to get it functional without this code drop? Or was it a complete blackbox with literally zero way of figuring it out via reverse engineering and the only people who could write the code worked at AMD cuz they knew what it actually needed?

[bridgman]

Hold up Bridgman, just to clarify. Is the firmware that is loaded open source or no? Michael made a comment about it "At least working with future kernels..." which made it sound like the firmware is closed source but the accessor functions that control it and direct it are open source and can therefore be patched and changed as the kernel goes.

Was there really any way for the open source developers to code for UVD and try to get it functional without this code drop? Or was it a complete blackbox with literally zero way of figuring it out via reverse engineering and the only people who could write the code worked at AMD cuz they knew what it actually needed?

Unfortunately Linux puts microcode in a folder called "firmware", which makes things confusing right from the start. The microcode that gets loaded into the chip is a binary image, just like the microcode that is permanently burned into devices. It's part of the hardware block design.

All of the driver code (ie everything that runs on the CPU) is open source. This is the same model as the rest of the graphics drivers.