AMD Releases UVD Engine Source Code

An anonymous reader writes "Years of desire by AMD Linux users to have open source video playback support by their graphics driver is now over. AMD has released open-source UVD support for their Linux driver so users can have hardware-accelerated video playback of H.264, VC-1, and MPEG video formats. UVD support on years old graphics cards was delayed because AMD feared open-source support could kill their Digital Rights Management abilities for other platforms."

Comments

Re:Yay?

[MatthewNewberg]

Helps with battery life, and can allow you to run other things while playing video without a large performance hit.

Re:Yay?

[click2005]

It makes the AMD platform much more appealing for low power media boxes.

Someone explain this to me

[buchner.johannes]

So the article links "The code just arrived" to a folder with .bin firmware files and this license:

REDISTRIBUTION: Permission is hereby granted, free of any license fees,
to any person obtaining a copy of this microcode (the "Software"), to
install, reproduce, copy and distribute copies, in binary form only, of
the Software and to permit persons to whom the Software is provided to
do the same, provided that the following conditions are met:

No reverse engineering, decompilation, or disassembly of this Software
is permitted.

Redistributions must reproduce the above copyright notice, this
permission notice, and the following disclaimers and notices in the
Software documentation and/or other materials provided with the
Software.

Did AMD actually release any source as the title suggests? Where is it? Or did they just make using/redistributing their firmware legal?

Re:Someone explain this to me

[Kjella]

Did AMD actually release any source as the title suggests? Where is it? Or did they just make using/redistributing their firmware legal?

There's three parts:
1. Microcode update (not open source, never was)
2. Kernel patches (open source)
3. Mesa patches (open source)

The first post leads to an email, but if you go to thread mode you'll see 10 kernel patches following it and the mesa patches are in the other link in the Phoronix article. This is a real open source driver, as open source as the rest of their driver. I must honestly say I'd given up hope that this would ever get released, but fantastic that it has. This has literally been years in the works, but now that the hurdles have been crossed hopefully this support is here to stay for future generations of cards as well.

Re:Someone explain this to me

[hattig]

Indeed it is. People are getting their knickers in a twist over microcode for the GPU (which is probably just a microcode update) that probably target a custom architecture, compiled by a custom compiler, and which in themselves provide the advertised functionality (decoding h.264, etc). It's firmware, it's conjoined to the hardware (which is also closed-source) to make the hardware do something useful. By having firmware, you can add features down the line (e.g., VP8, H.265) as well, that you couldn't do with totally fixed hardware.

Note that many CPUs include lots of microcode themselves, where the advertised ISA instructions are actually small microcode programs. Of course they're less complex than video decode microcode, but they're the same thing overall. The CPU microcode is probably also generated via a custom assembler/compiler or hand-written.

Nope, no source code. Just binary blobbage.

[girlinatrainingbra]

Nope, no source code. Just binary blobbage.
:>(
linky http://lists.freedesktop.org/archives/dri-devel/2013-April/036766.html leads to
linky http://people.freedesktop.org/~agd5f/radeon_ucode/
.
which is a directory full of .bin files of Radeon microcode patches. Does not appear to be source at all, even though the article at Phoronix claims that there is a release of "open source driver code": Within the next few hours AMD will be publishing open-source driver code that exposes their Unified Video Decoder (UVD) engine on modern Radeon HD graphics cards. This will finally allow open-source graphics drivers to take advantage of hardware-accelerated video decoding

A comment on their discussion page is more insightful and likely to be right:

This should read "AMD Releases UVD Support For (Partially) Open Source Driver" instead, since likely 90% (the exciting part; if it's anything like on NV) of the UVD code is pre-compiled in the blob firmware ... (the percentage may be open for debate)

So it looks like that comment is right: everything's hidden in a binary blob and there is no source code released at all at this time.

Re:Silly AMD

[hairyfeet]

Because you can't give away somebody else's IP without getting sued and possibly having your chips blacklisted? For those that don't know HDCP is property of Intel which means AMD had to sign a license agreement and NDA to allow their systems to support HDCP. Of course this gives Intel two advantages when it comes to their drivers, one they don't have to worry about IP since they own it and two because they've been ahead of AMD both on IPC and die shrinks they were able to keep HDCP pretty much a separate module in the designs VS AMD who used parts of their GPU for HDCP which is why they had to be VERY careful not to step into the IP minefield when they went about opening their chips.

Now personally i think it sucks balls that we ALL have to pay for this DRM being baked into the chips when so few of us are watching content protected by HDCP but as long as big media has a giant stiffie for DRM we are all just gonna have to accept it. I do hope this gets Linux users to put their money where their mouths are and support AMD, I don't know how many "LOL use Nvidia" posts I've seen from Linux users which you just have to be gobsmacked when you realize here is the guys that spend so much time talking about "freedom" while supporting the most FOSS unfriendly company there is. I mean there is a reason why Torvalds gave Nvidia the bird ya know, and it wasn't his way of saying they were #1. AMD has done every single thing the FOSS community asked, they are opening their chips, helping out with Coreboot support, they are probably one of the most FOSS friendly hardware companies there is so lets hope they see that support rewarded, otherwise companies are gonna look at the lack of support AMD got and decide that there is nothing to gain from being open.

Re:Nope, no source code. Just binary blobbage.

[tlhIngan]

The question is - the driver (the part that Linux runs) is open sourced. It just interfaces with parts that aren't (the firmware).

A modern graphics card is programmable - they run various programs (and you know them for doing stuff like GPGPU and CUDA, and even LLVM). So the firmware files are there to load the hardware decoder blocks onto the GPU.

For AMD cards, the card does the whole video decode chain - you feed it in h.264 or VC-1, and it parses the stream, decodes it and renders it all on the chip. nVidia cards require CPU assistance - they do the IDCTs and YUV transforms and other acceleration, but not the entire stream on card.

So they open-sourced the part your CPU runs, while the GPU part is still a binary blob that the driver loads onto the GPU so it can start feeding it the encoded stream and have the GPU decode and display it.

There's not much else to it - they could open source the firmware, but that's often highly proprietary and may contain licensed code from elsewhere. Plus, there may be a bunch of other technologies involved (i.e. the compiler) that they can't open-source. And most people won't have use for that code anyhow - it's firmware. It's just like the firmware that runs your WiFi card, your NIC, etc. - they often make the interface public and leave the rest of it proprietary.

Re:Silly AMD

[Kjella]

HDCP was not the issue here, that is the link between the DVI/HDMI port and the monitor. This was about AACS/CSS that is used by BluRay/DVD and the Windows DRM requirements, under the license agreements AMD must protect the video between it is sent to the binary driver as compressed video and is output through the DVI/HDMI port as decoded video. By exposing the hardware API they feared you may be able to snoop on the binary driver on Windows and intercept protected data, worst case it couldn't be fixed in software and AMD would lose all their certifications, all licensed software would update to refuse to play on AMD hardware and it couldn't be used by OEMs that want the "Made for Windows" stickers plus some incredibly ugly contract penalties. So yeah DRM, but not that DRM.

Re:Nope, no source code. Just binary blobbage.

[Anonymous Coward]

Nope, no source code. Just binary blobbage.

Then what the hell is all this:
http://lists.freedesktop.org/archives/mesa-dev/2013-April/037049.html

Re:Yay?

[TheRaven64]

The AMD Fusion boards come with 1.6GHz (Atom-equivalent) processors and integrated Radeons. They can't handle 1080p on the CPU, but can on the GPU. They're low power, so are good choices for home cinema boxes.