XBMC Developers Criticize AMD's Linux Driver

An anonymous reader writes "It's not only the NVIDIA Linux driver that has been publicly slammed over lacking support; the AMD Catalyst driver is now facing scrutiny from developers of the XBMC media and entertainment software. The developers aren't happy with AMD due to not properly supporting video acceleration under Linux. The AMD Linux driver is even lacking support for MPEG2 video acceleration and newer levels of H.264. AMD reportedly has the support coded, but they're refusing to turn it on in their public Linux driver."

Comments

"Refusing to turn it on"

[Anonymous Coward]

To me, the most interesting part of the summary was:

AMD reportedly has the support coded, but they're refusing to turn it on in their public Linux driver

The relevant point from the article seems to be

Our sources say that these features are implemented in fglrx since a long time, but simply not activated within the driver. Nobody seems to know why.

Forgive me for being skeptical with Phoronix, but does anyone with more direct knowledge of these "sources" want to comment? I'd like to have a better view of the situation than just the words "Our sources."

Re:Why should they?

[0123456]

Why should they support Linux leeches?

There's a reason why all my Linux boxes except the oldest one have either Nvidia or Intel graphics. In the case of the old one I had to manually patch the ATI driver kludge source because ATI dropped support and a kernel change broke it.

So, not a penny of my IT budget has gone to ATI since 2008 because their drivers aren't very good and they don't support them.

was annoying on XBMC for me

[forgottenusername]

I usually don't pay too close of attention to ATI vs Nvidia war, but I had built out a slick HTPC machine to run xbmc on Linux, and videos had all sorts of problems on the ATI card.. especially with decent quality videos. Hitching, crashing, general instability despite trying different drivers and config combinations.

Threw in a fanless nvidia, VDPAU works fine, totally different experience.

So, I'll stick with Nvidia on Linux for anything more serious than web browsing; their closed source binary driver is a little obnoxious, but at least it works.

Switchable Grpahics

[PerlJedi]

The video codecs are the least of my problems with linux support from both NVidia and AMD. Neither of them off any kind of support for switchable graphics under linux. I have laptops with modern graphics cards from each of these guys, and in both cases it has been a long up hill battle getting the graphics cards to work correctly.

Re:Switchable Grpahics

[Anonymous Coward]

The big problem there is that X itself doesn't have infrastructure to support switchable graphics sanely. There is some work being done to provide a Hot-Swap API into X11 to address this problem so at least then there will be a way to at least start to get this working in X.

The other big factor is that most of these switchable graphics solutions are proprietary per laptop. Some use a physical mux to switch the display back and forth between integrated and discrete cards. Some don't and use a purely SW solution where the discrete card renders offscreen, then has its output copied into system memory for compositing by the integrated card. Windows 7 sort of supports this now in their driver model with their WDDM compositor.

I'm sure something could eventually be worked on in Linux but there isn't any standard X driver model really created to make this work. I don't blame either company for not spending that much effort to get this working given the current marketshare of linux on laptops (which I think is pretty close to 0% as sold by OEMs). It makes me a bit sad, but until X gets support to make this whole switchable graphics thing a first class citizen I doubt either company will have much official support for this.

If Linux laptops were a big market segment and the manufacturers were clamoring for switchable Linux graphics because end users were willing to pay for it then you'd probably see this feature emerge. Sadly the market probably doesn't appear large enough to justify major investment.

Also do the open source AMD driver or Noveua support any sane form of switchable graphics? Or are they also stuck on X11's lack of a good API for this?

Re:Actually I care...

[corychristison]

I built my own HTPC, but the hardware appears to be very similar to what you have in your Dell Zino HD.

I am curious, what are the problems you had with the Ati Catalyst driver, and did you ever resolve your issues?

My system is a Jetway NC81-LF ITX board. Onboard Radeon HD 3200, AMD Athlon 64 X2 4850e CPU, 4GB DDR2 SODIMM & 30GB 2.5" HDD all retro fit into and old VHS player (I was bored one day). As an aside I plan to upgrade HDD to SSD soon. Whole system is only about 9GB. All media plays over NFS mount from my primary workstation.

I am running Gentoo Linux (kernel 3.2.12, w/gentoo patchset), Catalyst 12.4, Xorg server 1.11.4 and having no issues with any media. I do not, however, use XBMC, but a custom UI I've been working on that calls mplayer (eventually will be open sourced, currently working on integrating Youtube).

I did have to disable the sideport memory on my board though. If it was turned on I got a lot of tearing in video. I also set mplayer lavdopts threads to 2 (one thread per CPU core).

This setup is capable of playing anything I have ever thrown at it, including direct Bluray 1080p rips with no transcoding, even no issues with fast paced scenes (Disney's Cars & Rio).

mplayer config:
[default]
vo=gl
# force audio over HDMI
ao=alsa:device=plughw=1.3
# multithreaded CPU decoding
lavdopts=threads=2

# set languages
alang=en
slang=en

# disable subtitles
sid=999

Re:Actually I care...

[anomaly256]

And lets not forget that the requested features *already exist* within the driver code base. AMD just doesn't turned them on when building the linux package! This isn't the same as having to write interface code for a different window manager or library or kernel interface or something that requires an actual porting effort, this is internal code that talks to their firmware to send/receive data and process it on their hardware. It already does this for h264 THERE and turned on when building for windows. All they have to do is change a #ifdef and suddenly linux support catches up with windows in their driver. This really is a f*cking retarded situation and people are right to be angry at AMD for artificially limiting their experiences. Under the table agreements with a particular REALLY large software maker much? It seems to be the only explanation that causes this situation to make any kind of sense.