NVIDIA Releases Another 180.xx Beta Driver

[Kano]

I always compile new svn variants, you can even create

svn -r1 diff

and apply that to current xine hg sources (but those did not really change much). I don't think thats a xine issue, that purely the driver.

[deanjo]

I always compile new svn variants, you can even create

svn -r1 diff

and apply that to current xine hg sources (but those did not really change much). I don't think thats a xine issue, that purely the driver.

BTW, new mplayer patches should show up in a few minutes. Aaron is currently looking into why they are not on the ftp yet.

EDIT: Here they are,

http://people.freedesktop.org/~aplattner/patches/mplayer-vdpau-3263604.tar.bz2

[sylware]

There are two projects Radeon and RadeonHD. Radeon is not done by Novell, it's done by the FOSS community. Intel's drivers are still nowhere close in speed and reliabilty as their closed souce OS X and Windows cousins. Even with radeonhd, all are free to contribute. Development of the RadeonHD is not limited to Novell developers. They just happen to be the lead devels.

They are issues regarding the license: BSD license does not prevent the possibility of an improved closed source fork and then does not protect against the sub-optimal open source version syndrome. I speak for myself, for such reasons I do not provide BSD code, only GPL code (even AGPL). I won't come back on the novell case, but indeed it seems bad omens for the radeonHD driver.

So what you are saying is that previous foss attempts failed.

Actually you are trying to make me say that or want to hear what you would like. What I'm saying is we are interested in optimal open source version of drivers and then we don't care about proprietary drivers. In order to start proper development of drivers for the nvidia GPUs we need hardware programming specifications. Development is in progress for AMD GPUs and Intel GPUs with a great brainstorming on new user level and low level interfaces.

Linux did not become Linux in one day. Expect the same thing for GPU drivers.

I totally agree with that. They are constantly going back to the drawing board trying to fix their previously failed attempts. That's something that the nv blobs has not had to do, their performance has remained far more consistant then the foss drivers for any other graphics hardware and still performs better then the rest still to this day because they do not have to deal with the performance killing roadblocks that plague the foss drivers.

There is no failed attempts, it's a continuous progression. Actually if there is one failure, it's the reverse engineering of the setup of a tiled frame buffer on nv50 and above. In order to properly add nvidia GPUs to the supported GPUs of the newly brainstormed graphic stack, we need the hardware programming specifications.

And all that do not change the direct rendering issues I and some collegues have with the proprietary driver.

[deanjo]

They are issues regarding the license: BSD license does not prevent the possibility of an improved closed source fork and then does not protect against the sub-optimal open source version syndrome. I speak for myself, for such reasons I do not provide BSD code, only GPL code (even AGPL). I won't come back on the novell case, but indeed it seems bad omens for the radeonHD driver.

That should be an issue at all, if the FOSS developers are up to the task then they should not have to worry about someone forking and improving it.

Actually you are trying to make me say that or want to hear what you would like. What I'm saying is we are interested in optimal open source version of drivers and then we don't care about proprietary drivers. In order to start proper development of drivers for the nvidia GPUs we need hardware programming specifications. Development is in progress for AMD GPUs and Intel GPUs with a great brainstorming on new user level and low level interfaces.

Linux did not become Linux in one day. Expect the same thing for GPU drivers.

And I'm saying let the FOSS community first PROVE that they are up to the task before ragging on a close source solutions that have a proven track record of performing better then the open solutions.

There is no failed attempts, it's a continuous progression. Actually if there is one failure, it's the reverse engineering of the setup of a tiled frame buffer on nv50 and above. In order to properly add nvidia GPUs to the supported GPUs of the newly brainstormed graphic stack, we need the hardware programming specifications.

Again first the FOSS community has to prove that they can even pull off such a task. Up until this date they have not.

And all that do not change the direct rendering issues I and some collegues have with the proprietary driver.

Bugs happen in open and closed. It's a fact of life. freedesktop has an excellent report tabulator generate your own reports and you will see that there are hundreds unresolved bugs with foss drivers even with the chipsets that have full documentation. Some of them are even dating back close to 5 years ago.

[RobbieAB]

Even the all mighty Matrox with their foss drivers experience a big drop in performance and 3+ year old issues still plague many foss drivers.

I wasn't aware that Matrox had released specs for any of their Graphics cards since the Millenium G550, nor that they had anything other than a FOSS driver for the G550. They certainly didn't have a proprietry driver on their site for it when I looked...

[deanjo]

I wasn't aware that Matrox had released specs for any of their Graphics cards since the Millenium G550, nor that they had anything other than a FOSS driver for the G550. They certainly didn't have a proprietry driver on their site for it when I looked...

It's actually those older cards I was referring too.

[RobbieAB]

Well, they don't have a proprietry Linux driver for it, so it is hard to claim it is faster under a proprietry driver.

[deanjo]

Well, they don't have a proprietry Linux driver for it, so it is hard to claim it is faster under a proprietry driver.

Not really, the linux performance on those older cards is not near as good as their closed source windows counterparts.

[bulletxt]

ok where is this thread going to?

let's look at reality and present. as of today, the only real working driver that really does what a GPU driver should do, is the NVIDIA blob driver. AMD/Intel drivers have nothing got to do with the stable/powerful/complete NVIDIA driver.

now you can say anything you want, but this is a fact and there isn't much to say on this.

[Throwing Strikes]

I've never had a single problem using the Nvidia blob ever... It allows me to play my games flawlessly with zero headaches. ET:Quake Wars, Quake 4, ET:True Combat Elite, World of Warcraft, Warcraft 3, EVE (Last 3 under Wine) all work wonderfully for me.

For the people that have performance issues with ET:Quake Wars a low latency kernel is a requirement. FYI