Drivers for linux are rubbish

[mirv]

AMD have not officially released xvba - they might work on it and properly release it in the future, but there's been no word from them on that subject.
I've also had issues with vdpau - full X crashes actually. However this is on my nettop, so to say vdpau alone isn't entirely accurate - vdpau with xbmc is causing problems for me.

[pingufunkybeat]

I want people who are saying forgive fglrx, it's better now to not forget to mention it's still not perfect.

This is not the problem.

But recently, people have been claiming that FGLRX can't do any powersaving, that FGLRX crashes as soon as it renders a triangle, and all sorts of other nonsense.

It would be more fair to say that there are issues with tear-free playback and Xv colours, and that WINE in particular has some issues with 3d.

That would be a fair assessment, having read about the topic for months now.

Yet every week a new guy comes here and claims that he read on this and that forum that fglrx will blow up your computer.

It's getting very old.

[mugginz]

This is not the problem.

But recently, people have been claiming that FGLRX can't do any powersaving, that FGLRX crashes as soon as it renders a triangle, and all sorts of other nonsense.

If someone says fglrx doesn't do power saving of any kind then they're plainly wrong and there's nothing wrong with correcting them here.

If someone says fglrx crashes immediately upon rendering a single triangle then I'd hope that sound ridiculous to everyone and I'd have no problem with someone saying it's ridiculous.

It would be more fair to say that there are issues with tear-free playback and Xv colours, and that WINE in particular has some issues with 3d.

That would be a fair assessment, having read about the topic for months now.

I agree. Driver installation issues can and should be worked on by distros.

Yet every week a new guy comes here and claims that he read on this and that forum that fglrx will blow up your computer.

Anyone claiming that is taking pretty serious creative license at best but I also don't think that's what anyone's trying to get at at all.

It's getting very old.

And people wanting to sweep issues with <inset favourite vendor here> add nauseum is a bit old as well.

[albatorsk]

This is not the problem.

But recently, people have been claiming that FGLRX can't do any powersaving, that FGLRX crashes as soon as it renders a triangle, and all sorts of other nonsense.

Yet every week a new guy comes here and claims that he read on this and that forum that fglrx will blow up your computer.

Yet more straw men. Who's saying these things?

It would be more fair to say that there are issues with tear-free playback and Xv colours, and that WINE in particular has some issues with 3d.

But that's what we ARE saying. Please pay attention.

That would be a fair assessment, having read about the topic for months now.

The big problem is that it hasn't been a problem for months, it's been years. That's what some people, including me, get worked up about.

[pingufunkybeat]

Yet more straw men. Who's saying these things?

I don't need to name users and start flamewars again, but both the powersaving and the triangle one came in the last few days here on Phoronix.

The "blow up" one is my hyperbolic satire.

[droidhacker]

@droidhacker are you serious?

VDPAU is working with all kind of video type (MPEG-1, MPEG-2, MPEG-4 ASP (MPEG-4 Parte 2), MPEG-4 AVC, etc) since long ago. Some linux programmers have said that is a very good api and well implemented.

As I said, doesn't work AT ALL for me, and this speaks about someone dropping the ball somewhere along the line. If it was as rosy a picture as you portray, then it should have worked when I tried it.

And note: mpeg1/2 don't need any acceleration. Even the weakest crappiest cellphone CPU can handle those just fine. Even most h263 is fine. The only thing you REALLY need acceleration for is h264 (AVC).

XVBA, just work with a few video cocdecs (backend under VAAPI), just with with HD4000, and the programmer has explicity said on this forums that XBVA driver is plenty of bugs. Maybe if some day ati implements it correctly it will be fully functional. The hardware has the potential is just the api & driver is not yet working. And it seems that it will not work in short term

As I said, all you need is h264. The rest are cute, but irrelevant, and the choice between a broken AMD and an also broken NVIDIA... what does it matter? In fact, from what I've seen, AMD, though it may be buggy, WORKS. NVIDIA? I have yet to see it actually do anything besides crash!

VAAPI I don't know exactly how good bad it is, but i guess is worst than VDPAU.

There's your problem. You are making guesses that have no substance to them. The fact that devs tend to favor using VDPAU as a backend to VAAPI should say a lot to you.

I am not speaking about the APIs itselfs, but about the API and Driver implementation and functionality together.

The problem though is that there ARE two parts of it. The API and the backend implementation.
VAAPI has the advantage of being a UNIFIED API that stands in front of ALL the other existing implementations. VDPAU as an API is a FAILURE. VDPAU as a backend, in MY experience, is also a failure. That's two failures right there. Again, mileage may vary with luck, but it would be inaccurate to present it as something that *just works*, because it DOESN'T always work.

[mugginz]

As I said, all you need is h264. The rest are cute, but irrelevant, and the choice between a broken AMD and an also broken NVIDIA... what does it matter? In fact, from what I've seen, AMD, though it may be buggy, WORKS. NVIDIA? I have yet to see it actually do anything besides crash!

I guess I'm lucky. It just works for me. I bought a 8400GS passive card for $35 Australian. About $30 US I think. Put in my MythTV box, installed Kubuntu 10.04 and MythTV. Told Myth to output via VDPAU and hey presto, my Celeron system plays back high def without breaking a sweat.

By what you're saying I hope fglrx works as easily. If it does then that's one less thing on my personal list to worry about.

[Exopaladin]

I guess I'm lucky. It just works for me. I bought a 8400GS passive card for $35 Australian. About $30 US I think. Put in my MythTV box, installed Kubuntu 10.04 and MythTV. Told Myth to output via VDPAU and hey presto, my Celeron system plays back high def without breaking a sweat.

By what you're saying I hope fglrx works as easily. If it does then that's one less thing on my personal list to worry about.

Last I checked, it wasn't quite so easy to do VAAPI with MythTV, but with mplayer it's fairly trivial to set up. Of course, if you have an Evergreen (5xxx) card, you don't get VAAPI at all.

[Jimbo]

As I said, doesn't work AT ALL for me, and this speaks about someone dropping the ball somewhere along the line. If it was as rosy a picture as you portray, then it should have worked when I tried it.

Ok, you have a bad experience with vdpau. We have to extrapolate to general VDPAU?

And note: mpeg1/2 don't need any acceleration. Even the weakest crappiest cellphone CPU can handle those just fine. Even most h263 is fine. The only thing you REALLY need acceleration for is h264 (AVC).

Sorry but this is your personal point of view, and not a general one. I use mplayer-mt for video, but I can see that under some situations it is better to have video decoding acceleration on hardware, even mpeg2 1080 and 60 fps needs a fair amount of cpu power. Maybe you have a low power CPU or you want to use all your cpu power to encoding video while watching dvb-t HD content, or you are on a mobile with ultra low cpu power...

As I said, all you need is h264. The rest are cute, but irrelevant,

Again your personal point of view.

There's your problem. You are making guesses that have no substance to them. The fact that devs tend to favor using VDPAU as a backend to VAAPI should say a lot to you.

No, i am not making totally guesses, I have read here on phoronix article that intel has no good video acceleration using VAAPI yet, so if you point me with "substance" That intal + vaapi works better tha nvidia + vdpau I can learn, no problem.

I think the real problem are not the apis, Vaapi, vdpau or XVBA, is the driver/hardware implementation to support them. Nvidia has done a nice job with VDPAU.

[droidhacker]

Ok, you have a bad experience with vdpau. We have to extrapolate to general VDPAU?

I am NOT doing that. Go find where I said that it doesn't work for anybody any of the time. All **I** am saying is that it isn't NEARLY as workable as YOU seem to be suggesting. The problem we are facing here is that YOU seem to be reading about a minor glitch here or there regarding AMD software and assuming that it applies equally across the board. IT DOES NOT! AMD software is NO WORSE than nvidia! But EVERY SINGLE THING YOU SAY proves that you BELIEVE that it IS.

Sorry but this is your personal point of view, and not a general one. I use mplayer-mt for video, but I can see that under some situations it is better to have video decoding acceleration on hardware, even mpeg2 1080 and 60 fps needs a fair amount of cpu power.

WHO DOES THAT?
Sure you CAN, but there is literally ZERO MOTIVATION for it. MPEG2 is dead and relegated primarily to SD content. And if it's sucking up massive amounts of your CPU, then you're doing something wrong, like applying too many filters to the video post-decode.

Also note: I see that you have a multi-core CPU. Note that I set up a DVB card for someone about a year ago... she has a 1.6 GHz AMD Turion X2 -- not exactly the most powerful multi-core CPU you can get... to say the least. Using SINGLE THREADED decoding of OTA HD MPEG2, basically uses negligible CPU. It does have an nvidia GPU, but pre-VDPAU (GF6100, if I recall...), so obviously is NOT benefiting from decode acceleration.

Maybe you have a low power CPU

Low power CPU... sure. My netbook has an atom Z520. Low enough for you? On THAT machine, it takes NEGLIGIBLE CPU to decode MPEG2. Even HD MPEG2...

or you want to use all your cpu power to encoding video while watching dvb-t HD content,

Ok, so you've got a CPU strong enough to encode some kind of video. You're going to worry about 1% of ONE core being lost to decoding mpeg2?

or you are on a mobile with ultra low cpu power...

See above -- atom z520 decodes mpeg2 just fine. Unless you're referring to a CELL PHONE, in which case you're not running XVBA or VDPAU *anyways*, which makes the example irrelevant.

But just to put that into perspective, my CELLPHONE has a qualcomm MSM7201, which is an ARMv5 topping out at a whopping 528 MHz. EVEN IT will happily decode mpeg2 in software!

You know, the whole mpeg2 decode acceleration was introduced to deal with earlier REALLY SLOW CPUs.... like 80486. You may LIKE to do it now, but it is definitely NOT ESSENTIAL. Particularly when SO LITTLE CONTENT uses it!

Again your personal point of view.

As your personal point of view appears to be that AMD software is useless and can't possibly work for anyone.

No, i am not making totally guesses, I have read here on phoronix article that intel has no good video acceleration using VAAPI yet, so if you point me with "substance" That intal + vaapi works better tha nvidia + vdpau I can learn, no problem.

You really haven't been reading much then, because INTEL distributes a chipset known as POULSBO. I'm sure you've heard of it. Regardless of the issues it is known for, it DOES do video decode acceleration for MPEG2, ASP, and AVC. And it works. Trivially. VAAPI.

I think the real problem are not the apis, Vaapi, vdpau or XVBA,

Without a unified API, trying to (1) support all the different implementations is a nightmare, and (2) none of them end up working well.

is the driver/hardware implementation to support them. Nvidia has done a nice job with VDPAU.

I don't agree.
It is consistent with the extremely poor driver quality that I have come to expect from them. Works for some, not for others. Intel's implementation, on the other hand, seems to pretty much *just work*, as long as you are able to get their drivers installed (which can be something of a challenge).

And FYI about newer xservers and intel poulsbo support (before you come out and say it doesn't work on the latest xserver)... seems that the poulsbo driver *DOES* work on xservers newer than 1.6, except for an XSERVER BUG introduced in 1.7 (that carried through to 1.8). That basically means that those with poulsbo chipset have mpeg2, ASP, and AVC decoding working in systems running the latest kernel and fixed xserver now: https://bugs.freedesktop.org/show_bug.cgi?id=28077

But...but...but...but...

Sorry, but reading isn't everything. You can't possibly read everything, and what you NEED to read isn't necessarily WRITTEN, or written where you are reading. Sometimes you need to ASK the right questions... WHERE THE right people are lurking. Sometimes you simply need to try it out for yourself.