AMD Open Sources Their Linux Video API

← Back to Stories (view on slashdot.org)

AMD Open Sources Their Linux Video API

Posted by Roblimo on Saturday February 26, 2011 @12:42AM from the every-little-open-source-bit-helps dept.

An anonymous reader writes "AMD has open sourced X-Video Bitstream Acceleration, their API by which they expose the Universal Video Decoder 2 GPU under Linux." They may be a little late with this move, and not everything you could wish is now open source, but it's better than nothing.

64 comments

Min score:

Reason:

Sort:

Okaaaaaay... by MrEricSir · 2011-02-26 00:51 · Score: 4, Insightful

The ATI drivers for Linux were never perfect, but they worked decently. But ATI/AMD would drop support for older chips that were still in use. The open source community never provided a shim to let these older drivers work with newer builds of X.
Does open sourcing the drivers really fix the compatibility problem? To me, not building a shim suggests a general lack of caring about ATI drivers. Do we really need the source to give a future to aging ATI/AMD chips?

--
There's no -1 for "I don't get it."
1. Re:Okaaaaaay... by kangsterizer · 2011-02-26 01:42 · Score: 1
  
  Obviously its not just about "open sourcing the drivers", otherwise we'd have open sourced catalysts and all would be well.
  The reason catalysts work well and open source drivers don't is because, well, they're not the same code at all, and the catalyst ones are a lot more advanced.
  Now they want their view of the standard to be implemented so open source it, but theres other standards already out there, so it feels a bit like "just throwing it around hoping it works"
2. Re:Okaaaaaay... by PhobosK · 2011-02-26 02:15 · Score: 2
  
  Well that is too late I think... Something like using an umbrella after the rain has stopped... :)
  
  I already have a very bad experience with a couple of laptops with integrated old ATI cards which linux support was dropped by ATI 2 years after they were produced?!...
  
  So i have learned my lesson very well and it is - NEVER buy anything even closely related to ATI (though it is now AMD :) )...
  
  No one should make one and the same mistake again, shouldn't he?
3. Re:Okaaaaaay... by slash.duncan · 2011-02-26 02:50 · Score: 4, Informative
  
  Well, there's the proprietary drivers which AMD/ATI does what they want with, dropping support for old chips, etc, and there's the native xorg/kernel/mesa/drm and now KMS drivers, which are open. The open drivers support at least as far back as Mach64 and ATIRage, and while I never used those specific drivers, after I realized what a bad idea the servantware drivers were based on the nVidia card I had when I first switched to Linux, I've stuck with the Radeon native drivers. In fact, I was still using a Radeon 9200 (r2xx chip series) until about 14 months ago, when I upgraded to a Radeon hd4650 (r7xx chip series), so I /know/ how well the freedomware support lasts. =:^)
  And why would the free/libre and open source (FLOSS) folks build a shim for the servantware driver? The kernel specifically does NOT maintain an internal kernel stable ABI (the external/userland interface is a different story, they go to great lengths to maintain that stable), and if anyone's building proprietary drivers on it, it's up to them to maintain their shim between the open and closed stuff as necessary. Rather, the FLOSS folks maintain their native FLOSS drivers.
  And while for the leading edge it it's arguable that the servantware drivers are better performing and for some months may in fact be the only choice, by the time ATI's dropping driver support, the freedomware drivers tend to be quite stable and mature (altho there was a gap in the r3xx-r5xx time frame after ATI quit cooperating, before AMD bought them and started cooperating with the FLOSS folks again, part of the reason I stuck with the r2xx series so long, but those series are well covered now).
  So this /is/ good news, as it should allow the freedomware drivers to better support hardware video accel, as they merge the new information into the freedomware drivers.
  
  --
  Duncan
  "Every nonfree program has a lord, a master,
  and if you use the program, he is your master."
  R Stallman
4. Re:Okaaaaaay... by Anonymous Coward · 2011-02-26 03:32 · Score: 0
  
  servantware
  
  freedomware
  Yep... time to quit reading Slashdot.
5. Re:Okaaaaaay... by Bengie · 2011-02-26 04:23 · Score: 1
  
  ATI has better drivers and better cards than nVidia for the Windows platform. Too bad they haven't invested much into Linux :*(
  
  My $300 6950 out would out-perform a similar $300 card from nVidia, and consume less power and run A LOT cooler. Instead, I OC'd it 100mhz and unlocked a bunch of shaders. Now it smears the floor with another $300 nVidia card. System has been perfectly stable. My friends with nVidia on the other hand, they still have black screen bugs back from 3 generations ago on their new 470s. They say their next cards are going to be AMD/ATI after many loyal years to nVidia and empty promises of bug fixes.
  
  meh, the grass is always greener on the other side.
  
  Personally, I'm biased against nVidia because they market like Intel. They make a great product, but I loath them for ethical reasons.
6. Re:Okaaaaaay... by Anonymous Coward · 2011-02-26 04:30 · Score: 0
  
  lol
7. Re:Okaaaaaay... by next_ghost · 2011-02-26 05:20 · Score: 2
  
  X.org and Linux kernel developers don't care about any closed source software. When somebody chooses to release software as closed source, he decides that nobody else can update it themselves. Why should open source developers make his life easier by restricting the pace of development of their own software? Open source developers didn't force him to release the software as closed source. Open source software on the other hand can be easily updated to keep up with the pace of upstream development by anybody.
  I own 3 generations of ATI hardware (Mach64/Rage 3D Pro, R200/Radeon 8500, M56/Mobility Radeon x1600) and in general, the closed source driver implements more hardware features but on the other hand, the open source driver is MUCH more stable. ATI is my graphics card brand of choice but I'd rather get Intel than deal with closed source driver again.
8. Re:Okaaaaaay... by Smauler · 2011-02-26 07:38 · Score: 1
  
  My Gigabyte gtx460 is 100% stable and runs relatively cool. Under load it'll sometimes get up to 60-70 degrees (with pretty crappy case cooling ATM - my front fan has given up). The lowest I've ever seen it at was 10 degrees. That was in December, when it was cold out, and I don't heat my house when I'm at work. My PC is on 24/7 though... I was suprised it was running so cold - the CPU was at about 15 degrees IIRC. I'm guessing ambient temperature must have been about 5 degrees.
  I had a look at all the options when I bought it, and bang for buck the GTX460 was the best card for me. I usually buy just below cutting edge.
9. Re:Okaaaaaay... by Bengie · 2011-02-26 07:57 · Score: 1
  
  Try an Antec 900 for a case. About $100, but hard to beat for it's price. My videocard went from 90c to 40c, but I to had a crappy case.
  
  Other than the lack of tool-less setup, it is an excellent case.
10. Re:Okaaaaaay... by WorBlux · 2011-02-26 08:48 · Score: 2
  
  Not neccessarily, the graphics industry is a hotbed of patent litigation waiting to happen. Open sourcing the complete driver would open up a lot of proof for attacks through the courts. Opening up any of it to open source is a huge deal, and show the continuing shift in willingness of manufacturers to work with the linux foundation to provide the best possible experience on the hardware for any potential use. ATI on just linux that's broken, it's the OpenGL support, wchich lags behind even in thier windows drivers.
11. Re:Okaaaaaay... by Anonymous Coward · 2011-02-26 09:45 · Score: 0
  
  It's always been like that here. You can always spot the loonies because they use words like "GNU/Linux" and "FLOSS". Nobody else uses these words.
  See you over at Linux Hater's Blog!
12. Re:Okaaaaaay... by MrEricSir · 2011-02-26 13:04 · Score: 0
  
  This kind of "us vs. them" thinking is a failure both in politics and in software.
  If we're more concerned with the licenses than whether or not our computers work, then we've failed as programmers and become lawyers.
  
  --
  There's no -1 for "I don't get it."
13. Re:Okaaaaaay... by silanea · 2011-02-26 21:47 · Score: 1
  
  I disagree. Open Source is not just about the Ubuntu image you can download today, it is about how we create and use software 20 years from today. It took a long time to get hardware vendors to hand out specs or show genuine interest in delivering Free drivers. And here we are, with at least two big players (AMD and Intel) pledging their support and another (NVIDIA) at least playing along somewhat.
  
  --
  Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
14. Re:Okaaaaaay... by next_ghost · 2011-02-27 01:01 · Score: 2
  
  There is no "us vs. them" in this case. There are two software packages, one open source, the other proprietary. Why should developers of the open source package cripple their own software just to keep the proprietary one working? Developers of the propiretary one made the decision to prevent everybody else from contributing fixes and updates. If you're dissatisfied with results when they can't or don't want to keep up with changes in related open source packages, blame the proprietary developers for making wrong decisions.
15. Re:Okaaaaaay... by MrEricSir · 2011-02-27 10:43 · Score: 1
  
  20 years ago, FLOSS advocates were saying the exact same thing.
  And yet, my computer's graphics chip STILL doesn't work. I'm sick of the excuses.
  
  --
  There's no -1 for "I don't get it."
16. Re:Okaaaaaay... by glitchvern · 2011-02-27 18:28 · Score: 1
  The ATI drivers for Linux were never perfect, but they worked decently. But ATI/AMD would drop support for older chips that were still in use. The open source community never provided a shim to let these older drivers work with newer builds of X.
  
  Does open sourcing the drivers really fix the compatibility problem? To me, not building a shim suggests a general lack of caring about ATI drivers. Do we really need the source to give a future to aging ATI/AMD chips?
  As of January 19 phoronix, puts the average speed of the latest available open-source driver at roughly 70% the speed of the Catalyst driver before the pre-R600 support was discontinued in early 2009. This is using composite results from the ATI Radeon X1800XL, Radeon X1800XT, and X1950PRO graphics cards being benchmarked on Nexuiz, Warsow, OpenArena, World of Padman, and Urban Terror. These cards use the R300g driver. Newer cards using the R600g driver (cards with HD in the name) are not currently anywhere near these results.
  
  A bit of history:
  
  A long time ago, documents describing the specifications of graphics cards were generally available under NDA to XFree86 developers. Then Nvidia started releasing binary only drivers. ATI eventually followed suite. The last series with docs available from this era is ATI's R200. The R300 released in 2002 did not have docs released for it. Following the lack of docs, driver development stagnates.
  
  April 6, 2004 XFree86/X.org fork.
  After Keith Packard was kicked out of the XFree86 core group and XFree86 switched to non-gpl compatible license a fork ensues. Project Leadership of XFree86 had been basically hostile to developers and had retarded increases in the developer base and improvements in the graphics stack for literally years. Following the fork a renaissance in X Server development begins.
  
  July 24, 2006 AMD acquires ATI.
  Speculation about open drivers begin.
  
  May 10, 2007 Red Hat Summit
  AMD's Henri Richard says something about improving the open source drivers. Speculation becomes flood of rumors.
  
  September 06, 2007 ATI/AMD's New Open-Source Strategy Explained
  AMD announces plans to contribute specification documents and code to the open source drivers. By this time successive X.org releases have seen:
  
  Removal of XIE, PEX and libxml
  Window translucency, XDamage, Distributed Multihead X, XFixes, Composite
  EXA, major source code refactoring. Switch to autotools build system instead of Imake
  EXA enhancements, KDrive integrated, AIGLX
  Removal of LBX and the built-in keyboard driver, X-ACE, XCB, autoconfig improvements
  Input hotplug, output hotplug (RandR 1.2), DTrace probes, PCI domain support.
  September 11, 2007 XDS2007 Program
  The "softpipe" talk by Keith Whitwell of Tungsten Graphics is the earliest reference I can find to Gallium3D. References to Gallium3D show up on Tungsten Graphics website at approximately the same time according to internet archive. Apparently Tungsten Graphics released a softpipe driver (gallium driver for cpu) at this time, along with a "proof of concept" i915 driver.
  
  September 12, 2007 AMD Releases 900+ Pages Of GPU Specs
  RV630 Register Reference Guide and M56 Register Reference Guide.
  
  January 04, 2008 AMD Releases Additional R600 GPU Programming Documentation
  M76 and RS690 register guide weighing in at 458 and 422 pages respectavly. Contains LVTMA and i2c information not found in previous docs. LVTMA is the second digital output block on the ATI R500/
17. Re:Okaaaaaay... by next_ghost · 2011-02-27 23:46 · Score: 1
  
  And yet, my computer's graphics chip STILL doesn't work. I'm sick of the excuses.
  And which one is that? Because right now, the R300g driver (supporting R300-R500 chips) is about to pass Catalyst with a loud woosh in 3D performance. It has passed Catalyst with much louder woosh in 2D performance and stability ages ago. The R600c driver also makes Catalyst eat dust in 2D performance and 3D works fine on older cards (HD5xxx support is still weak because ATI released specs less than 6 months ago).
18. Re:Okaaaaaay... by pigeon768 · 2011-03-02 06:14 · Score: 1
  
  The fglrx drivers were terrible. They were ludicrously unstable. From what I understand, they eventually got better, but they would crash the system (ie, straight to POST, not just X11) on a regular basis for years.
  Writing a compatibility layer for old drivers is a very tricky business. Specifically, it's the business of the writers of the old drivers. Only they know what arcane deprecated functionality their software uses, not the writers of the interface.
  Open sourcing the API to the drivers did fix the problem. The open source drivers support ATI hardware all the way back to the first generation radeon.
this is good news by bmalia · 2011-02-26 00:53 · Score: 4, Interesting

I have always purchased nVidia cards soley because I knew that they provided linux drivers. Lately though, the drivers don't seem to work quite right. Might be getting to be about time for me to give ATI a go.

--
There's no place like ~/
1. Re:this is good news by Urza9814 · 2011-02-26 04:14 · Score: 1
  
  I've used nothing but ATI and nothing but Linux for 6+ years now and I've never had any issues. I am of course using the proprietary ATI drivers though. And I never buy the latest, top of the line video cards.
2. Re:this is good news by janwedekind · 2011-02-26 04:30 · Score: 2
  
  If you don't need cutting edge graphics, give Intel Graphics a go. The drivers are free software -> distributors are permitted to integrate them properly -> installation is a breeze.
3. Re:this is good news by bmcage · 2011-02-26 04:52 · Score: 0
  
  If you don't need cutting edge graphics, give Intel Graphics a go. The drivers are free software -> distributors are permitted to integrate them properly -> installation is a breeze.
  Unfortunately, everybody actually needs cutting edge graphics ...
4. Re:this is good news by Mr.+Slippery · 2011-02-26 05:27 · Score: 1
  
  Unfortunately, everybody actually needs cutting edge graphics ...
  For what?
  
  --
  Tom Swiss | the infamous tms | my blog
  You cannot wash away blood with blood
5. Re:this is good news by bmcage · 2011-02-26 06:20 · Score: 1
  
  You don't use those nice Desktop Effects I presume. Did you take a look at how Apple promotes it's upcoming Lion? My wife's laptop with Intel is a joke compared to mine. I need good graphics for work. Of course, it might be the open source drivers that suck.
6. Re:this is good news by Anonymous Coward · 2011-02-26 07:05 · Score: 0
  
  In the last 10 years, even now, whenever someone tends to have problems in X with something not working or crashing, it is generally Intel or AMD video chips. All I can say is nVidia has worked exceptionally for myself in the last 10 years. I also have Intel graphics, but those (used to?) crash in the 3D driver..
  So yes, you can go and test ATI. Please let us know how it turns out, especially if you use 3D acceleration.
7. Re:this is good news by Knuckles · 2011-02-26 07:08 · Score: 2
  
  Intel's 3D is plenty capable of desktop effects and stuff like Google Earth. Compiz runs perfectly. When the GP wrote "cutting edge graphics" he was talking about stuff like Crysis 2 and maybe professional 3D use. Few people actually need that.
  
  --
  "When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
8. Re:this is good news by Anonymous Coward · 2011-02-26 07:49 · Score: 0
  
  They do work well if you're using a distro like Ubuntu that controls the versions of the drivers and kernels. If you use a constantly up-to-date rolling release like Arch, it's not worth the hassle to keep constantly checking for compatibility with new software. It's horrible to download a new kernel, reboot, and then find out your drivers don't work.
  I don't play any games on my computer, so I can use the open source drivers without worrying. It would be nice if they got faster for those times I do want 3D, though.
9. Re:this is good news by janwedekind · 2011-02-26 08:56 · Score: 1
  
  My laptop has an Intel Mobile Series 4 graphics card. KDE compositing rarely drops below 25 frames/second.
10. Re:this is good news by BitZtream · 2011-02-26 09:30 · Score: 0
  
  Wow, that must suck. Your GUI allow eats so much CPU power that you can't maintain a good frame rate? I can't imagine trying to get anything done on a machine with GUI lag anymore, let alone a GUI which maxes out a CPU which I'd prefer to be using myself.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
11. Re:this is good news by tepples · 2011-02-26 12:05 · Score: 1
  
  KDE compositing rarely drops below 25 frames/second.
  If it drops below 60, it's not keeping pace with your monitor.
Yet Another API by arivanov · 2011-02-26 00:54 · Score: 2

Sigh... That makes what? 4 or 5 different APIs.
Original XvMC
Via XvMC VLD extension
Nvidia - three options - legacy, their bitstream and using CUDA
Intel
Sigh... Can't we just get along and agree on a single standard?

--
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
1. Re:Yet Another API by MrEricSir · 2011-02-26 01:12 · Score: 2
  
  Fractured API standards are the standard in the open source world. Just look at A/V APIs, web rendering APIs, KDE vs. GTK, etc.
  As long as they can work together programmatically, it's not necessarily a bad thing to have different APIs.
  
  --
  There's no -1 for "I don't get it."
2. Re:Yet Another API by cardpuncher · 2011-02-26 01:34 · Score: 1
  
  And, since it requires the Catalyst driver, I assume it's tied to X (like VDPAU) which means that integrating into something like DirectFB isn't going to be possible. As far as I can tell the APIs are not only different in detail but different in the way they are abstracted which means it's quite difficult to have them "work together" in any meaningful way.
3. Re:Yet Another API by Chuckles08 · 2011-02-26 01:47 · Score: 2
  
  This does seem to be a recurring theme in the open source world. On the one hand, it's great to have/try lots of approaches but we need a more effective way of elevating the most successful to the top. Seems like connecting social media more closely with these types of projects would enable discussion and opinions to act as a catalyst for promoting effective solutions.
  
  --
  Twenda Learning: Educational Apps that Engage.
4. Re:Yet Another API by Kjella · 2011-02-26 02:01 · Score: 1
  
  Well XvMC will never do more than MPEG2, so it's not suited for much of anything.
  As far as modern codecs go, nVidia has VDPAU, Intel has VA API and ATI has XvBA. Why everyone needs to reinvent the wheel I don't know, but there it is. I figure eventually someone will write the right wrappers so apps only need to deal with one API.
  
  --
  Live today, because you never know what tomorrow brings
5. Re:Yet Another API by Ant+P. · 2011-02-26 02:14 · Score: 2
  
  VA-API is the only standard that makes sense to implement, unless you like limiting your apps to nvidia/ati users only, or like writing three times as much code.
6. Re:Yet Another API by u17 · 2011-02-26 02:15 · Score: 4, Informative
  
  I figure eventually someone will write the right wrappers so apps only need to deal with one API.
  VA-API is the wrapper that you speak of. It has multiple backends, including backends for Intel cards, VDPAU and XvBA.
7. Re:Yet Another API by Xua · 2011-02-26 02:22 · Score: 1
  
  Actually Intel's VA API has backends that use VDPAU and something from FRGLX. I am not sure these backends are tested well but in theory an application that uses VA API can use acceleration provided by all three major graphics hardware vendors. In addition to decoding VA API can be used to accelerate encoding and post-processing filters.
8. Re:Yet Another API by Anonymous Coward · 2011-02-26 07:16 · Score: 0
  
  It's a new one called Gallium.
9. Re:Yet Another API by simcop2387 · 2011-02-26 08:51 · Score: 1
  
  in fact up until this release it was only ever possible to use XvBA through VA-API. now there's a possibility of that changing but i doubt it. Instead i believe this will result in a more stable XvBA backend for VA-API so that it'll end up easier to use.
10. Re:Yet Another API by BitZtream · 2011-02-26 09:38 · Score: 2, Insightful
  
  And this is something that most people in the OSS world (has nothing to do with OSS in general, just OSS allows it to happen easier) utterly fail to grasp.
  The bad thing with multiple APIs, that all do essentially the same thing is that they give 'choice'. I realize that most OSS users and indeed most techies LOVE choice, the rest of the world doesn't. Or rather, its not so much that they don't like choice, its that they are not educated about the choice enough to answer them effectively.
  GTK vs Qt/Gnome vs KDE is a great example, here its not the users choice thats a problem its the developers. Some devs use KDE, some use GNOME, some use their own toolkit, some use X primitives directly. And combine that all together on a desktop and you get one big ugly fucking mess where everything works slightly different and the user just ends up frustrated because they don't spend their entire lives having a circle jerk to discuss which GUI toolkit should rule them all.
  Multiple choices are NOT ALWAYS A GOOD THING, especially when you don't have the domain specific knowledge to make the choice, or someone else that knows nothing about you or your needs is making the choice for you.
  The Linux desktop is example of why choice is not always a good thing.
  I know, what I just said was complete blasphemy here, but its true.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
11. Re:Yet Another API by Anonymous Coward · 2011-02-26 13:34 · Score: 0
  
  On the other hand you fail to see there is no choice.
  Look at GTK vs Qt that you noted. Are they really different? Nope, both use X11 with a standard window manager and implement various freedesktop specs. In fact, almost all backend systems are standardized, with user-facing systems poping up left and right as various programmers tinker with their pet projects, and as various desktops have a NIH syndrome. The reason for a lack of a real video acceleration API on X is the general lack of X design development combined with the failed XvMC that was obsolete almost as soon as it was released (by note, the more general and older Xv is still in use) giving the impression that creating such a extension was pointless.
  People may scream about too much choice and how it stops progress but in reality most serious choices are already made by higher-up system standardizing on existing standards and systems. The real problem is when these higher-up systems develop new systems but dont spin them off as standards for other projects to use. This leads to true duplication of effort, and is largely seen in the audio area: various sound systems for each desktop (needlessly), various backends. By comparison the video space is fairly clean: a few codec implementations (not really duplicates), some players using these codecs and shims to use binary codecs, then you have desktop-specific systems arise to provide a unified API for using these codecs which does duplicate work.
  So in conclusion: the problem is not really too much choice, but a general lack of development due to no industry standards (after all, open source is about implementing commodities), combined with NIH and the need for "portability" preventing various desktop projects from trying to standardize a new shared, but possibly OS-specific, system, especially when it comes to audio.
12. Re:Yet Another API by Anonymous Coward · 2011-02-26 16:30 · Score: 0
  
  That's why going Microsoft is for the best. No point in having Apple, even though it looks pretty it conflicts with what everyone else is using.
13. Re:Yet Another API by Anonymous Coward · 2011-02-26 22:14 · Score: 0
  
  no one uses X primitives directly anymore...
VDPAU is already an open standard by CajunArson · 2011-02-26 01:20 · Score: 3, Informative

Nvidia's VDPAU is already an open standard that other video drivers can implement in Linux for video acceleration, so I'm not sure what this buys us. VDPAU as implemented by Nvidia is also about the only video acceleration standard that isn't totally broken and that can accelerate videos beyond MPEG-2 as well.

--
AntiFA: An abbreviation for Anti First Amendment.
1. Re:VDPAU is already an open standard by Anonymous Coward · 2011-02-26 01:40 · Score: 2, Insightful
  
  independence from binary-blob drivers is what it buys us.
2. Re:VDPAU is already an open standard by Anonymous Coward · 2011-02-26 01:46 · Score: 1
  
  It's not true that VDPAU is the only working standard for linux. My Notebook has an Intel Arrandale GPU which works fine with Intels open-source video driver and can decode H264 HD through VA-API just fine.
3. Re:VDPAU is already an open standard by drinkypoo · 2011-02-26 03:05 · Score: 1
  
  VA-API is an open standard, what's wrong with it? Allegedly both ATI and nVidia cards can backend it (nvidia through VDPAU, ATI through whatever wacky stuff they use.) And of course intel provided it so it works with intel.
  nVidia has the only accelerated OpenGL pipeline that works worth a crap on any platform. Now THAT is interesting.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
4. Re:VDPAU is already an open standard by 3.1415926535 · 2011-02-27 10:59 · Score: 1
  
  VA-API is an open standard, what's wrong with it?
  Its display functionality is totally inadequate.
Not open sourced by Kjella · 2011-02-26 01:47 · Score: 5, Informative

This headline is widely misleading. They've now documented their equivalent of nVidia's VDPAU blob, but it's only available when you run the closed source Catalyst driver. TFA says so quite clearly.

Before anyone starts wondering, this won't do much good for those hoping to see AMD's UVD2 engine supported by the open-source Radeon graphics drivers.

--
Live today, because you never know what tomorrow brings
1. Re:Not open sourced by Anonymous Coward · 2011-02-26 02:06 · Score: 1
  
  It's doubly misleading, because API stands for Application Programmer's Interface, and an interface in the context of computer programming means headers/protocols, which by definition aren't compiled and don't have any source. Hence you can't "open-source" an interface.
What's the reality? What is usable for MythTV? by Anonymous Coward · 2011-02-26 05:17 · Score: 0

ATI has had video acceleration since ~1996, but never anything usable for Linux. As a long time MythTV user, I gave up on them a long time ago. What's the AMD/ATI reality today? Do they have usable APIs, have any apps supported them?
I tried the Intel video accel stuff, which showed promise as fully open source. It wasn't ready for prime time when I tried it ~2 years ago. Is that usable for HD playback in anything now?
Nvidia, while being closed source, has at least had options for Linux users. XvMC mostly worked, although not without its problems. VDPAU is excellent. The little Atom/Ion platforms with VDPAU are ideal for HTPC use.
Intel is left alone by Anonymous Coward · 2011-02-26 05:28 · Score: 0

atlast he AMD/ATI have showed some interest in linux ... :)
Re:What's the reality? What is usable for MythTV? by jedidiah · 2011-02-26 06:41 · Score: 2

You can use what actually works while you wait for some academic or aesthetic ideal.
Some like to whine about how there are too many APIs around but the actual coders just take care of business. At least the Free Software coders do. That is why the libre tools for Linux are so much better at using this sort of stuff than what proprietary software exists for Linux.
If nvidia is no longer the only game in town then that can only be a good thing.

--
A Pirate and a Puritan look the same on a balance sheet.
Now only if by tabrnaker · 2011-02-26 07:17 · Score: 1

they would release their internal hardware accelerated build of FFMpeg
1. Re:Now only if by Anonymous Coward · 2011-02-26 11:37 · Score: 0
  
  probably not possible.
  contains 3de party IP stuff they cant release.
2. Re:Now only if by tabrnaker · 2011-02-26 12:39 · Score: 1
  
  Who cares about the code. I'd settle for a binary.
Nvidia by ruinevil · 2011-02-26 08:30 · Score: 1

I feel that nVidia uses the same drivers for all operating systems. The core doesn't change, it just has a wrapper to interface with X/DirectX/Quartz. They just update the core significantly once in a while, to the point it can't interface with older cards. That's why the occasionally have huge issues.
Is this really needed? by TeknoHog · 2011-02-26 09:52 · Score: 1

Mplayer-uau (basically mplayer with full multithreading) plays 1080p H.264 on an Atom D510 without any hardware decoding. I have given up with GPU video decoding on Linux, since software works so well even on fanless processors.

--
Escher was the first MC and Giger invented the HR department.
1. Re:Is this really needed? by Anonymous Coward · 2011-02-26 14:05 · Score: 0
  
  At what bitrate? Even the fairly old nvidia 9400 can do 1080p H/264 at Bluray bitrates, whereas an Atom has gotta be working all-out at gigabyte-per-hour bitrates. While I do think it's inevitable that we'll eventually get to the point where ~10 Watt CPUs will be up to the job of obsoleting hardware decoders, that's several years off.
2. Re:Is this really needed? by godrik · 2011-02-26 14:11 · Score: 1
  
  In my experience, Atom processors do not play high resolution very well. But even if it did, having a version that uses the GPU would be a significant improvement. It would free the CPU to do potentially something else. Including downclocking, which could improve energy efficiency significantly.
  On my PDA (Nokia N810), I used to decompress audio using a software lib. When I switched to a lib that uses the internal DSP, my battery life increase 300%.
3. Re:Is this really needed? by Anonymous Coward · 2011-02-26 17:29 · Score: 0
  
  It plays 720p H.264 on a single-core 1.6ghz Atom as well, on top of a single-channel DDR2 memory bus. With minimal post-decoding hardware assist for scaling and YUV->RGB conversion and so forth via Xv.
  Atoms derive quite significant advantages from software that's multithreaded. I suppose this means their single-thread performance kinda sucks, which is true compared to something like a 1.33ghz mobile core i3.
4. Re:Is this really needed? by TeknoHog · 2011-02-26 22:04 · Score: 1
  
  In my experience, Atom processors do not play high resolution very well. But even if it did, having a version that uses the GPU would be a significant improvement. It would free the CPU to do potentially something else. Including downclocking, which could improve energy efficiency significantly.
  Good point, but the power consumption of a Radeon is not exactly zero, even at idle. If you need to add a discrete GPU to shave off a few CPU watts, I believe the overall consumption increases.
  
  On my PDA (Nokia N810), I used to decompress audio using a software lib. When I switched to a lib that uses the internal DSP, my battery life increase 300%.
  Another good point. Unfortunately, this AMD announcement does not do much help in the mobile space.
  There is also the general point that hardware acceleration is lagging behind new codec development. Software is much more flexible, even when "hardware" means new drivers/firmware for a general-purpose DSP. In this day and age it would be much more interesting to see codecs written in OpenCL, for example.
  
  --
  Escher was the first MC and Giger invented the HR department.