Slashdot Mirror
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."
Your DRM was cracked years ago, so why stall for so long?
hardware accelerated playback for cpus that have no issue playing 1080p content. Guess this will help anyone stuck with a netburst P4 or Celeron.
Only the State obtains its revenue by coercion. - Murray Rothbard
So the article links "The code just arrived" to a folder with .bin firmware files and this license:
Did AMD actually release any source as the title suggests? Where is it? Or did they just make using/redistributing their firmware legal?
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
And can't do 1080p w/o hardware excel. My CPU might be old, but it's still miles ahead of an i3 and bumps up against the low end i5s.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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
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 firmwareSo 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.
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.
Okay, thanks for the info. But where exactly is the link for and where exactly is the source code for the "open source" API to this proprietary firmware code blob? I agree that open sourcing the interface is useful alone: knowing what the hooks are lets you access more of the capabilities of the card.
Thats not acceptable. This is why we need to go out and produce our own hardware. An impossible task it might seem. Its not really though. If you actually look at the numbers it's just an extremely difficult task. The sole reason it is such a difficult task is because the users don't care or don't know to care. The end result is we end up with substandard support. Stuff that doesn't work, doesn't work right, or stops working down the line. We need a policy of release it all or we won't use it/don't want it.
ThinkPenguin's got that basic policy and they are don't extremely well. They have the biggest catalog or at least the largest variety of hardware anywhere.
Tried reading the +5 informative comment posted 1 hour before yours?
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
That comment you're referring to was posted 13 minutes after my comment which is currently a +4 informative comment. I just hadn't followed the thread and seen it. Nyah. so there. :>p
"By exposing the hardware API they feared you may be able to snoop on the binary driver on Windows and intercept protected data"
And by selling a gun, S&W fear you may use it to hold up a bank or commit murder.
I would think the APIs would be "documented" by the source code that was released. After all, the code would show how to load a program onto the GPU, get it running (it's not a trivial operation considering all the things that have to be set up so the GPU can run your code amidst everything else it does).
Then the driver will have to interface between userspace and get the video data to the card, which the code will show as well. The firmware being loaded is specific to video decode, so there wouldn't be much to it - just grab the block of video data, somehow point the card at it via bus mastering (DMA), and kick the firmware into decoding it at the right time.
You won't access more capabilities because the firmware you loaded only does one thing - it's a program that configures the card to do hardware video decoding. Depending on the video, it may demand so much GPU resources that the GPU can't do 3D rendering as well, kicking the system into 2D mode (on Windows, it would be switching from Aero to Basic). Or maybe not (e.g., a DVD won't do it, but a Blu-Ray will), if the load is small.
There's very little the firmware offers software - just enough hooks to be able to decode the video. You can't use it to render triangles or mine bitcoins or whatever with that firmware - you have to load in your bitcoin mining firmware or 3D render pipeline firmware to do those things (these things are normally done by asking the driver to compile and load your GPGPU code).
At best, you'll learn how the IPC works between the host CPU and the GPU.
Not a fork of GCC, but of Open64, which is the old SGI MipsPRO backend plus a GCC frontend.
Agree with the post, though.
No, it's because Intel has a choice of having their fortunes tied to Microsoft's (as is the case on the desktop) vs having a largely community developed platform, w/ some in-house development to fine tune the result. Since Intel doesn't make its money selling software or drivers, to them, it is irrelevant whether their software is open sourced or not. However, it does help them to be open sourced as they then have a largely ready made platform viz. Linux, on which they develop the rest of whatever they need. That was the case with Meego, and it's the case with anything that they made to ensure that the platform is successful.
Insofar as the bulk of legacy software on the desktop had been Wintel, the Microsoft relationship worked wonders in helping Intel get a big readymade advantage on RISC platforms, even while their manufacturing reduced the gap between the 2. OTOH, the very same relationship saw to it that Intel's own attempts to get away from the x86, like the Itanium, failed for the very same reason. Incidentally, FOSS would have been not just the ideal, but the only solution that would have worked had Itanium been a pure VLIW architecture, as opposed to EPIC initially and multi-processing EPIC later, since recompilation would have been needed w/ every generation.
This isn't the 90's anymore...
GPU drivers, today, aren't targetting hardware directly. It's not like one fires up Carmageddon, which talks to Glide, which talks to graphics card anymore.
Here's to illustrate what's going on, going from hardware to application:
0. Hardware: processes data;
1. Firmware: tells binary to go this way or that way;
2. Kernel drivers (called the Direct Rendering Manager): Memory manager buffers to time-slice between all kinds of GPGPU apps (like OpenGL, OpenCL, MPEG*-decoding, etc.), scheduler to schedule the apps and KMS for 2D shiny correct-resolution stuff;
3. Bytecode, aka IR (Intermediate Representation);
4. LLVM-driver to convert library (OpenGL, OpenCL, etc.) stuff to Gallium3D IR;
5. Library with routines from API to LLVM driver;
6. Apps/frameworks/whatever.
The driver for the UVD is called a state tracker (lib[5] plus driver[4]). Everything below [3] is graphics card specific. The rest is vendor-agnostic.
Since there needs to be a State Tracker, in this case a VDPAU implementation in the Mesa "pipe-video"-branche (merged with master), it's not AMD specific at all. (works with nouveau (Gallium3D nVidia driver) It is, however, called a driver.
Then there is the scheduler, memory and firmware stuff. They need to adress Gallium3D IR, by sending it to the appropriate driver.
So you will not, whatsoever, be looking at a single driver, to learn how AMD does their DRM. (as in Digital Rights Management, not to be confused with the Direct Rendering Manager)
It's like a Java VM, so with a correct LLVM CPU backend driver, one can run heavily threaded GPU stuff directly on the CPU, which is dumb as hell for end usage.
Here be signatures
Thanks for the detailed reply. I'm fairly new to a lot of this, but still very interested in it. I'm also writing X11 code, using Xlib routines rather than an overlying window manager style thing. I'm not a masochist, I'm just trying to learn the details from some good X examples. I've written some OpenGL stuff also. And I'm interested in learning the details from the ground up and from the high-level abstractions down. Get the devil in the details squeezed from above and below, if I can. Again, thanks for outlining the layers.
.
I was also trying to learn the kernel drivers for some frame-buffer stuff for intel, as my dad bought an el-cheapo notebook. I can get X running just fine with Knoppix 7.04 and 7.05 for the notebook itself (which has 1024x600 pixels), but when you also try to use the hdmi output, it doesn't work. You always get a 1024x600 window with noisy (nonblinking) trash pixels around it on the HDMI screen to the full extent of the HDMI screen's pixel dimensions. I tried to see if I could inject (poke values directly into the video-buffer ram) some pixels outside of the recognized screen area, and thus learn how the memory mapping of the screen is capable of throwing the extraneous pixels on the HDMI screen, but the Xorg X display driver is only putting the display's pixels on the truncated 1024x600 window on the upper left. It's frustrating. (it's a walmart special Acer netbook, with the intel chip and the integrated video chip, 97xx maybe I don't remember off of the top of my head.)
X.org is now pretty much implemented as a State Tracker for Gallium3D ;) 2D networking X11 stuff in Xlib doesn't work if compoziting and using 3D, so that's why X11 is being axed and replaced by HTML5 in the widget toolkits Qt and GTK, and also by Wayland. Wayland sits on top of what X.org now sits on, and is purely a Window Manager.
Xlib is outdated, even for X.org. X.org now uses XCB (X.org C-Bindings).
If you want to poke at the frame buffer, try directly talking to the Kernel Mode Setting driver ;)
Here be signatures