If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Digging Deeper Into AMD's UVD Code Drop

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

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.

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?

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

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?

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.