Drivers for linux are rubbish

[mugginz]

I don't use vlc (except in Windows). Even with the little tearing that I have noticed once in a while, though, fglrx is still more functional and reliable for me than the nvidia drivers were. Unlike nvidia, at least fglrx doesn't result in a full system lockup.

Adam

And if for you you had lockups with nVidias blobs it's as valid to state that as it is to state that you have to use specific software to playback video with fglrx.

...Or is mentioning that you had lockups with nVidia bashing nVidia?

[adamk]

I haven't accused anyone of AMD bashing (or nvidia bashing).

Personally, I have no problems with people stating specific problems they've had with any software. It's when they do things like insist that one piece of software is always the better option, or always sucks, or is always rubbish that the conversation turns from intelligent discourse to bashing.

Adam

[mugginz]

I haven't accused anyone of AMD bashing (or nvidia bashing).

Personally, I have no problems with people stating specific problems they've had with any software. It's when they do things like insist that one piece of software is always the better option, or always sucks, or is always rubbish that the conversation turns from intelligent discourse to bashing.

Adam

Well I see a fair bit of posting regarding fglrx's performance as compared to nVidia's blob that on the balance of probabilities you're likely to have a better experience with nVidia than ATI at the moment and there's nothing controversial about that to me.

[Jimbo]

Not really... cuda is proprietary whereas openCL is open. That's enough to make all the difference.

I know cuda is propietary, but it seems that is used vastly on parallel computing programing and that is more easy to implement and has more performance than opencl, but not by a great margin. You can use google scholar and search some articles here. Although, I admit that I have a very vague idea, based on a few articles I read. I guess that in the future openCL will be the way to go because is open.

AMD has this too, even intel for that matter. They just use a different name for it.

Nvidia implemented VDPAU, and it seems much better than VAAPI and XBVA. This has been widely said by a lot of people. Now VDPAU (as API) is open and any vendor can use it.

[koshcu]

I have definitely had problems with nvidia recently. Their vdpau stuff cuttoff was basically one model card beyond mine so that does nothing for me.

However their driver quality has been falling off pretty quickly over the last few years for 2D stuff. They keep adding interesting new features but the driver seems to be more unstable. Most of the time you still can't go to the terminal from inside x (Ctrl-Alt-F1) for instance without it completely glitching up and often completely locking the computer up.

So if something goes wrong and x locks up in some strange way which has become more common with the nvidia driver and xinerama if you want to fix it you have to go to another machine and ssh in to fix it.

[Jimbo]

@ mugginz

You mixed some quotes, you qouted me on things I have no said.

Man / boy / whatever, you are just tedious. Do you know exactly what is the shape, pros and cons of fglrx and nvidia since long time ago. What do you want? Do you want us to erect a monument to nvidia better drivers? your song is always the same.

[droidhacker]

Nvidia implemented VDPAU, and it seems much better than VAAPI and XBVA.

What do you base this statement on?
From my observations, regardless of whose implementation you use, you put compressed video in one side and it plays back full screen HD on the other without sucking up your CPU.

From my EXPERIENCE, VDPAU simply *does not work*. Not saying that it won't work for anyone, but after spending several hours struggling with a GPU that was supposed to be supported, I decided that it just wasn't worth it -- it wasn't working for me, and there was no sign that it would ever (and FYI: I'm an engineer, not a newb).

Also, VAAPI is to be the general API for video decoding (at least this is the way things appear to be moving). VDPAU or XVBA are just two backends. Some applications are configured to access the backend directly, but that doesn't make it appropriate behavior. Nvidia sure TRIED to get THEIR API to be accepted as the general interface, but that doesn't look to be happening for them.

Note: The REASON they want their API to be accepted has to do with MARKETING. It would be valuable to them to say that they led AMD and Intel into conforming with THEM. From an open source freedom perspective, unless nvidia actually contributed to open source drivers, and SERIOUSLY (like AMD does), then it would be unsuitable to use any of their API, free or not.

This has been widely said by a lot of people. Now VDPAU (as API) is open and any vendor can use it.

Does it give you that warm fuzzy feeling to use something developed by the closed steel trap company?

Right now, the only SERIOUS user of VDPAU (as an api) is nvidia itself. The other user of it is S3, but we all know that they're not going anywhere. XVBA is used more appropriately as a backend under VAAPI. Intel implements backend for VAAPI more directly rather than exposing their backend to the user. VAAPI frontend exists for VDPAU (for those lucky enough to get it to work). So in the end, VAAPI should theoretically get you where you need to go and the backend implementation becomes irrelevant -- they all do the same thing (assuming that they work). VAAPI is most definitely ahead of VDPAU (as an API) in this regard... because VAAPI bas backends for AMD, Intel, AND VDPAU (which includes Nvidia *as well as* S3). There is NO AMD or Intel backend to VDPAU.

[mugginz]

@ mugginz

You mixed some quotes, you qouted me on things I have no said.

Man / boy / whatever, you are just tedious. Do you know exactly what is the shape, pros and cons of fglrx and nvidia since long time ago. What do you want? Do you want us to erect a monument to nvidia better drivers? your song is always the same.

I want people who are saying forgive fglrx, it's better now to not forget to mention it's still not perfect. I don't want people to build an expectation that can't currently be met. If you tell people they'll have no problems with fglrx and they then go and spend their money and then have problems that are well known by some then that's bad.

[Jimbo]

@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 ...)

[Jimbo]

@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.

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

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

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