Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
AMD Graphics Open Source

AMD Releases UVD Engine Source Code 79

Posted by Soulskill
from the new-toys dept.
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."
This discussion has been archived. No new comments can be posted.

AMD Releases UVD Engine Source Code

Comments Filter:
  • Re:Yay? (Score:5, Insightful)

    by click2005 (921437) * on Tuesday April 02, 2013 @10:43PM (#43344713)

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

  • Re:Silly AMD (Score:5, Insightful)

    by hairyfeet (841228) <bassbeast1968@@@gmail...com> on Tuesday April 02, 2013 @11:39PM (#43344939) Journal

    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 [wikipedia.org] 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:Silly AMD (Score:5, Insightful)

    by Kjella (173770) on Wednesday April 03, 2013 @12:05AM (#43345075) Homepage

    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.

  • by hattig (47930) on Wednesday April 03, 2013 @03:46AM (#43345799) Journal

    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.

Be careful when a loop exits to the same place from side and bottom.

Working...