NVIDIA Releases Another 180.xx Beta Driver

[phoronix]

Phoronix: NVIDIA Releases Another 180.xx Beta Driver

In roughly the past month NVIDIA has released five beta display drivers for the Linux operating system. NVIDIA began by releasing the 180.06 driver that brought PureVideo-like features to Linux in the middle of November...

http://www.phoronix.com/vr.php?view=Njk1Mg

[deanjo]

No word has been given by NVIDIA as to when the NVIDIA Linux 180.xx series may leave beta.

Little bird says January.

[sylware]

nvidia proprietary driver is a mess for a compositing window manager using direct rendering. And using indirect rendering, which is quite slower, you do not get vsync(=very ugly).
Well... we really need a GPL driver (certainly not BSD in order to assert that the open source driver will be the best).

[marakaid]

Too late for me, some weeks ago I resigned using Linux for gaming, tired of issues like bad performance in Quake Wars and strange problems with Nvidia, like KDE4 desktop effects activating high performance mode on the videocard, OSS4 drivers still not completed for soundcard, etc ...

Now I use my most powerful computer as a gaming machine only with XP 64 and all the other serious task with the second in line, with Ubuntu/Debian 64 bits.

Maybe it's still a victory for Linux camp, is not it? my best PC relegated as "Windows XP Console Game Mode", to each their own.

Nice Christmas for you all.

[sylware]

Too late for me, some weeks ago I resigned using Linux for gaming, tired of bad performance in Quake Wars and strange problems with Nvidia.

Now I use my most powerful computer as a gaming machine only with XP 64 and all the other serious task with the second in line, with Ubuntu/Debian 64 bits.

Maybe it's still a victory for Linux camp, is not it? my best PC relegated as "Windows XP Console Game Mode", to each their own.

Nice Christmas for you all.
Wow, you are a lucky guy. I bared with nvidia until quake 4 only. I had so many issues when upgrading my kernel and their drivers... I let down gaming for good. More over, now I run 64 bits only systems and most games are 32 bits only.
Really, if nvidia could release their hardware programing specs... and let us have a proper GPL driver in the main Linux tree... everything will be brighter, but they keep their hate generator to the max.

[marakaid]

Wow, you are a lucky guy. I bared with nvidia until quake 4 only. I had so many issues when upgrading my kernel and their drivers... I let down gaming for good. More over, now I run 64 bits only systems and most games are 32 bits only.
Really, if nvidia could release their hardware programing specs... and let us have a proper GPL driver in the main Linux tree... everything will be brighter, but they keep their hate generator to the max.

My computer dedicated for Linux and serious things (work, video editing, some servers) is still powerful with a Core2 Duo processor and a G33 mainboard that integrates everything I need, while staying nearly silent.

One thought I can share with you: Is if I have been "sensing" Nvidia performance and/or support for games degrading for more than a year; maybe my memory is not clear, but I remember playing in Debian Etch near the end of 2006 - half of 2007 playing the available games at that moment, (with a K8 AMD, 7600GT, 1GB ram) like Quake4, UT2004 very satisfying.

Something has changed on most recent Linux distributions or Nvidia drivers; I have been trying (32 bit and 64 bit mode included) Ubuntu, Mandriva, Debian, Slackware, and many others I can't remember; the only distribution where I played Quake Wars nearly the same as Windows (or at least where I felt it smooth, I don't like FPS scores) was Arch Linux 32 bits, somewhere in summer 2008, with my best PC (specs on the signature).

[Dragoran]

nvidia proprietary driver is a mess for a compositing window manager using direct rendering. And using indirect rendering, which is quite slower, you do not get vsync(=very ugly).
Well... we really need a GPL driver (certainly not BSD in order to assert that the open source driver will be the best).

wth are talking about ?
currently the nvidia driver is the only one that works reliable with direct rendering + cm.

The intel/radeon drivers with DRI2 are still not ready for usage yet.

And compiz works fine without any slowdown or corruptions now (the ones introduced in 167.07 where fixed with the first 180.xx ) release.

[sylware]

wth are talking about ?
currently the nvidia driver is the only one that works reliable with direct rendering + cm.

The intel/radeon drivers with DRI2 are still not ready for usage yet.

And compiz works fine without any slowdown or corruptions now (the ones introduced in 167.07 where fixed with the first 180.xx ) release.
No.
We are several to experience really messy direct rendering with a compositing window manager with latest drivers (180.15). Our common point is a display of 2500x1600@60.
And come on... a pb started in 167.07 and fixed in 180.xx... how long did it take? Is nvidia mocking us? Really that's insulting.
They should release their hardware programming specifications and put a GPL driver in the main Linux tree.

[deanjo]

No.
We are several to experience really messy direct rendering with a compositing window manager with latest drivers (180.15). Our common point is a display of 2500x1600@60.
And come on... a pb started in 167.07 and fixed in 180.xx... how long did it take? Is nvidia mocking us? Really that's insulting.
They should release their hardware programming specifications and put a GPL driver in the main Linux tree.

First of all, there is no 180.15 drivers or 167.07 for that fact.

Second, the mailing lists, forums, etc are full of OSS driver issues as welll for other cards. Propriety closed drivers still offer the better performance and features then open drivers for cards that have both regardless of the vender. FOSS has yet to prove that they can deliver on providing a reliable, top performance driver in video.

[sylware]

First of all, there is no 180.15 drivers or 167.07 for that fact.
http://svn.liveforge.org/berkano/trunk/x11-drivers/nvidia-drivers/nvidia-drivers-180.16.ebuild It's even worse than with previous drivers.

Second, the mailing lists, forums, etc are full of OSS driver issues as welll for other cards. Propriety closed drivers still offer the better performance and features then open drivers for cards that have both regardless of the vender. FOSS has yet to prove that they can deliver on providing a reliable, top performance driver in video.
First, the nvidia proprietary drivers aren't reliable: that's why we are several to complain.
To what are you comparing the nvidia proprietary drivers to???? There are no reasonable alternative drivers since the hardware programming specifications have not been released!
Let us have the hardware programming specifications... and then we'll see, shall we? :D

[Xanikseo]

The nvidia proprietary driver has never failed me.
We're comparing this driver to every linux video driver available.
It has VDPAU, which works very well and which all other linux drivers must catch up with.
Fact is, nvidia driver is most reliable, and IMO the best all-rounder.

So there. I don't see what all the fuss is about.

[bulletxt]

if people complain for NVIDIA drivers, then AMD users should suicide (me included).

how silly you guys are complaining of NVIDIA.

anyways, NVIDIA with all these releases and new things is just kicking AMD ass. and there isn't much to say about this.

[deanjo]

http://svn.liveforge.org/berkano/trunk/x11-drivers/nvidia-drivers/nvidia-drivers-180.16.ebuild It's even worse than with previous drivers.


First, the nvidia proprietary drivers aren't reliable: that's why we are several to complain.
To what are you comparing the nvidia proprietary drivers to???? There are no reasonable alternative drivers since the hardware programming specifications have not been released!
Let us have the hardware programming specifications... and then we'll see, shall we? :D

So you link me to a 180.16 driver, that is not a 180.15 driver. Fact holds true.
Propriety closed drivers still offer the better performance and features then open drivers for cards that have both regardless of the vender. Guess you missed that part. While you maybe having issues with the blobs it does not mean that everybody is having the same level of difficulty as you are. By your own admittance the issue you have is isolated to people running at 2500x1600@60. You also have to account that many people that have issues often is a result of improper setup and the people that do not have issues rarely post, "Just thought I would start a post saying my driver works".

Perhaps you haven't noticed the mailing lists, forums, irc, etc and the ongoing issues that people are experiencing with FOSS drivers as well. In some cases the performance in those have drastically dropped and still have yet to achieve the performance and feature level of their blob counterparts that is fact. Open drivers have shown a history of erratic perfomance and are just as bug ridden if not more. The slowest driver for intel and amd are still their linux opensource drivers. Compared to their closed source bretheren they are left in the dust especially when it comes to any serious 3d load such as pro/e, maya, etc. Using the opensource driver for apps such as those is equivelent to giving oneself a bikini wax treatment to ones genetailia every time one of those apps are loaded. 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.

The facts remain true. For the best overall experience and performance in linux with minimal pain the blobs are the only real contender at the moment. Get the performance of the current foss drivers (such as ATI and intel) first up to a level that they can compete with their blob counter parts compared to their windows and os x drivers and then you actually might have a valid argument. Until then foss has not proven that they are up to the task. Blobs steadily increase in performance, the same cannot be said for the current foss drivers. Let foss developers show off that they are up to the task with what they currently have and then we will talk about opensourcing the blobs. Until then, keep your fingers off them, I prefer the the performance and stability that the blobs have over their opensource alternatives.

[bulletxt]

@deanjo

you couldn't have explained it better. I'm happy to see there are people like you around here..

[sylware]

You all missed the point: There is no discussion to have till the hardware programming specifications are not released. For the moment, there is a tolerated blob and bare hate. The people at nvidia are very good at generating hate against them.
Once they are released, the linux community will start to code proper drivers.

Just let the hardware programming specifications go.

[deanjo]

You all missed the point: There is no discussion to have till the hardware programming specifications are not released. For the moment, there is a tolerated blob and bare hate. The people at nvidia are very good at generating hate against them.
Once they are released, the linux community will start to code proper drivers.

Just let the hardware programming specifications go.


FOSS developers can't even match the performance of blobs on the stuff that they do have the complete documentation for (ati/intel/matrox etc). Get those up to snuff and then they have proven themselves they are up to the task. Reality vs idealisms. It's you my friend that does not see "the point". Your "point" has no basis of proven development that the foss developers can even pull it off on even the hardware that they do have all documentation needed.

[sylware]

FOSS developers can't even match the performance of blobs on the stuff that they do have the complete documentation for (ati/intel/matrox etc). Get those up to snuff and then they have proven themselves they are up to the task. Reality vs idealisms. It's you my friend that does not see "the point". Your "point" has no basis of proven development that the foss developers can even pull it off on even the hardware that they do have all documentation needed.

it's not FOSS, it's novell, a microsoft proxy. We do not expect anything good from them, on the contrary. For the moment, only intel has proper drivers and they are very good for their hardware.
Moreover if you look at what is happening in graphic stack you should be aware that a lot of work is done designing new interfaces. Having the specs would help a lot, understand, the specs of all significant GPU models including nvidias.
So it's not only a matter of writting drivers but also writting a whole new stack. Additionnaly, the purpose of many in the community is to have GPL and optimal drivers. We are not interested in sub-optimal GPL drivers compared to proprietary forks or versions.

[deanjo]

it's not FOSS, it's novell, a microsoft proxy. We do not expect anything good from them, on the contrary. For the moment, only intel has proper drivers and they are very good for their hardware.

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.


Moreover if you look at what is happening in graphic stack you should be aware that a lot of work is done designing new interfaces. Having the specs would help a lot, understand, the specs of all significant GPU models including nvidias.
So it's not only a matter of writting drivers but also writting a whole new stack. Additionnaly, the purpose of many in the community is to have GPL and optimal drivers. We are not interested in sub-optimal GPL drivers compared to proprietary forks or versions.So what you are saying is that previous foss attempts failed. 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.

[Kano]

Well VDPAU with h264 dvb ts streams via kaffeine leads to screen corruption here (using xine-vdpau). Sometime a bit longer, but it happens. That's really annoying. Since 180.16 - older drivers don't compile with xine-vdpau.

[deanjo]

Well VDPAU with h264 dvb ts streams via kaffeine leads to screen corruption here (using xine-vdpau). Sometime a bit longer, but it happens. That's really annoying. Since 180.16 - older drivers don't compile with xine-vdpau.

Heh like they say in their IRC channel:

Experimental stuff, new decoders from scratch, expect bugs, crashes, smoke ..

BTW you might want to try again with the latest xine-vdpau commit that was just made 20 minutes ago.

[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

[sylware]

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.
Don't agree, see darwin/macos case as an exemple. BSD is not good protection enough. GPL only, even AGPL. It's a matter of personnal choice and beliefs. But it comes down to lock my GPL siblings and me out of the developement of the new graphic stack (I wanted to code on nouveau project but the answer was no since I would have provided Linux GPL code).

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.

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

There is nothing to prove. Again you do not want to understand: we don't care about proprietary drivers. We want "optimal" GPL drivers. And to do so we need the hardware programming specifications for all mainstream GPUs, then nvidias. It'll take the time needed:Linux did not become Linux in one day, then in order to loose as less time as possible, the earlier we get the specs, the better.

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.

Software has bugs, we agree. The proprietary drivers have many and are a mess for direct rendering in a composited desktop. I had to switch to indirect rendering and then I lost the vsync.

[sylware]

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.

That thread for some and me seems to evolve around:
- the hardware programming specifications goind public in order to program GPL drivers properly for nvidia GPUs. nvidia is the last of the mainstream GPUs manufacturers that has not released the hardware programming specifications.
- the blob (latest) is a mess using direct rendering in a composited desktop(seems to be related to 2500x1600 desktop size, but it's not confirmed). Additionnaly, switching to indirect rendering does not provide vsync.

[deanjo]

Don't agree, see darwin/macos case as an exemple. BSD is not good protection enough. GPL only, even AGPL. It's a matter of personnal choice and beliefs. But it comes down to lock my GPL siblings and me out of the developement of the new graphic stack (I wanted to code on nouveau project but the answer was no since I would have provided Linux GPL code).

And that's their right. It's their project.


There is nothing to prove. Again you do not want to understand: we don't care about proprietary drivers. We want "optimal" GPL drivers. And to do so we need the hardware programming specifications for all mainstream GPUs, then nvidias. It'll take the time needed:Linux did not become Linux in one day, then in order to loose as less time as possible, the earlier we get the specs, the better.


So your saying that nvidia lack of releasing programming specifications is holding back GPL development with other already available, fully documented GPU's? I don't think so. Like I've said before, show first that the community is able to achieve such lofty goals first with what they have and then take on a new challenge.


Software has bugs, we agree. The proprietary drivers have many and are a mess for direct rendering in a composited desktop. I had to switch to indirect rendering and then I lost the vsync.

There are just as many bugs in the FOSS drivers as there is in the blobs, again if not more. You had to switch to indirect rendering, fortunately a majority of blob users don't have to do that and enjoy pain free same day features and support on their brand new cards.

[sylware]

And that's their right. It's their project.
I respect their choice and I don't try to find ways I can use to imped their work. That's why if code there is from me, it will be another driver. But we still can share the knowledge of reverse engineering. So there is a lot of common ground.

So your saying that nvidia lack of releasing programming specifications is holding back GPL development with other already available, fully documented GPU's? I don't think so. Like I've said before, show first that the community is able to achieve such lofty goals first with what they have and then take on a new challenge.

We are talking about nvidia GPUs. Having full hardware programming specifications of AMD and Intel GPUs won't help me program nvidia GPUs. Then "...lack of releasing programming specifications is holding back " nvidia drivers "GPL development..."
Yes, indeed.

There are just as many bugs in the FOSS drivers as there is in the blobs, again if not more. You had to switch to indirect rendering, fortunately a majority of blob users don't have to do that and enjoy pain free same day features and support on their brand new cards.
hum... that would be amazing support (I wonder why I'm pushing for GPL drivers, really I wonder...).

Let's focus also on the issue: direct rendering in a composited desktop has bugs using the proprietary blob. Is there a place where I can report the issue and expect it to be fixed?

[Dragoran]

First of all, there is no 180.15 drivers or 167.07 for that fact.

Second, the mailing lists, forums, etc are full of OSS driver issues as welll for other cards. Propriety closed drivers still offer the better performance and features then open drivers for cards that have both regardless of the vender. FOSS has yet to prove that they can deliver on providing a reliable, top performance driver in video.

There was a 169.07 beta driver.
The reason why it took so long to fix this corruption issue is that the nvidia guys couldn't easily reproduce it (was talking with them on IRC) once they where able to reliable reproduce it they fixed it,

[sylware]

There was a 169.07 beta driver.
The reason why it took so long to fix this corruption issue is that the nvidia guys couldn't easily reproduce it (was talking with them on IRC) once they where able to reliable reproduce it they fixed it,
Great, which IRC network and which channel?
I'm going to help them reproduce the issue: I currently have 3 differents systems having the bugs.

[Janusz11]

Using the opensource driver for apps such as those is equivelent to giving oneself a bikini wax treatment to ones genetailia every time one of those apps are loaded.

* Laughs his ass off *
:D

Mate, you just made my day!


Well, and to contribute in some form to this thread: I have yet to experience any problem with my nVidia card. I'm absolutely happy with it- and I know what I'm talking about: I have just replaced my ATi Radeon HD4870 with a GeForce GTX260 OC Maxcore. And the first one was a pain in the neck compared to the GeForce.

Do I care that nVidia do not give away the specs of their cards to enable people to hack a open source driver? Nope! Its their decision and the closed one is working fine for me.

So, to nVidia I may say thanks and keep up the good work!

And to you all here I say: Merry Christmas and have a jolly good time!

[deanjo]

Let's focus also on the issue: direct rendering in a composited desktop has bugs using the proprietary blob. Is there a place where I can report the issue and expect it to be fixed?

You gripe about not having nvidia not fixing bugs but yet you have not filed a bug report? Email a detailed bug report to linux-bugs@nvidia.com as stated on the driver download page.

When emailing linux-bugs@nvidia.com, please attach an nvidia-bug-report.log, which is generated by running "nvidia-bug-report.sh".

How can you seriously gripe about poor support when you don't even use the resources provided?

[DeepDayze]

7900 GS here and no issues so far...

Now why bash on nVidia when ATI is far worse?

[bulletxt]

ahahah you make me laugh! you are wining for an issue with resolution 2600xxxx??? do you want me to list the 230 page known bugs of AMD/Intel driver? do you want me to list all features/implementation NVIDIA has and AMD/intel don't? what is this a joke? do you want me to list the 10000 pages of bugs(excluding the known ones) of AMD/Intel?

oh come on people.....if I continue reading this thread I'll start believing cows can fly.

[Kjella]

Let me just draw up a couple outcomes:

a) The open source community with some help from the participating companies gets their act together and deliver a state of the art drivers and infrastructure for all graphics cards that will open their specs.

b) The open source community continues to remain a divided bunch of experimental efforts (different driver projects, infrastructure projects that go nowhere, license issues and so on) that never really catch up with current technology and hardware.

This is already an experiment in progress for AMD. The question seems to be whether nVidia should join them or not. If you think that comes for free, you can't have been hanging out here very long. I don't know how many hours AMD has spent on compiling and clearing documentation (apart from their code contributions) but it's been many. What have they really gotten in return?

I know it's frustrating not being able to track down a bug but from nVidias point of view, is it worth spending 1000 hours to get 10 hours of minor fixes back? No. If they don't believe that the OSS community will ever amount to much, releasing specifications has no business case.

Of course, then someone will always say "Release the specs and we'll build a great driver for you, just you see!". If you want nVidia to release specs, the best you could do is get an AMD card and start hacking to make that a smashing success. Or at least that it'll give enough in return that clearing specs isn't a complete waste of time.

In short, I'll take a good blob over poor open source any day. If the alternative is dual-booting into Windows, which is all blobs then it's still the better option even though I prefer open source. Not above everything else though.

[deanjo]

Let me just draw up a couple outcomes:

a) The open source community with some help from the participating companies gets their act together and deliver a state of the art drivers and infrastructure for all graphics cards that will open their specs.

b) The open source community continues to remain a divided bunch of experimental efforts (different driver projects, infrastructure projects that go nowhere, license issues and so on) that never really catch up with current technology and hardware.

This is already an experiment in progress for AMD. The question seems to be whether nVidia should join them or not. If you think that comes for free, you can't have been hanging out here very long. I don't know how many hours AMD has spent on compiling and clearing documentation (apart from their code contributions) but it's been many. What have they really gotten in return?

I know it's frustrating not being able to track down a bug but from nVidias point of view, is it worth spending 1000 hours to get 10 hours of minor fixes back? No. If they don't believe that the OSS community will ever amount to much, releasing specifications has no business case.

Of course, then someone will always say "Release the specs and we'll build a great driver for you, just you see!". If you want nVidia to release specs, the best you could do is get an AMD card and start hacking to make that a smashing success. Or at least that it'll give enough in return that clearing specs isn't a complete waste of time.

In short, I'll take a good blob over poor open source any day. If the alternative is dual-booting into Windows, which is all blobs then it's still the better option even though I prefer open source. Not above everything else though.

Bingo, foss fanatics put up or shut up with what you have now, reach a level that rivals the blobs and then start saying that your ready for the next challenge.

[bridgman]

The good news is that the open source community does seem to be coming through. Right now probably seems like the "worst of times" from a user perspective because all of the important changes in the open source stack are just starting to come to life and if anything you are seeing a short-term reduction in performance and stability, but that will pass over the next 6 months.

I know everyone would like it to take a couple of weeks rather than a couple of years, but it is happening, and surprisingly quickly given the magnitude of the changes and the number of people involved.

[bulletxt]

The good news is that the open source community does seem to be coming through. I know everyone would like it to take a couple of weeks rather than a couple of years, but it is happening. Right now probably seems like the "worst of times" from a user perspective because all of the important changes in the open source stack are just starting to come to life and if anything you are seeing a short-term reduction in performance and stability, but that will pass over the next 6 months.


I understand your point and I am the first one to be happy. But when you buy bread, do you eat it after 1 year? No. Hardware isn't different. If I pay for something, it has to do what it's meant for immediately. Now this discussion can go on for 20 pages, but this is a fact (unless there are crazy users that in year 2020 use a Radeon 9600XT).

So to make it simple, what I see as a solution, is that all amd employes that code FGLRX should just stop with that sh*t. it's a fact that it is sh*t so there isn't much to say about this. and phoronix, please please stop it with FGLRX articles. Every FGLRX driver introduces 2 incomplete features, fixes 2 bugs and generates 20 new bugs. ok? stop it.

Instead of sending them home, they get the code they think can be useful, they open source it and start working together with the comunity. Don't even try to tell me some of them already work with novel and those nice stories. AMD MUST INTERRUPT THE CODING OF THAT SHI*TTY driver and invest in the open source one. If AMD doesn't stop that sh*t, it means they already know the open source one will never be as it should. be serious and stop what I can consider the worst driver in the linux market.

this is the only real solution I see as of today. for the rest, if you want to use your today card in year 2011 then ok, but in that case I would be stupid to tell someone to buy AMD cards if they use Linux and the choice will go automatically to NVIDIA.

let's be serious guys, when you buy an icecream you eat it before it melts. same goes for a GPU card.

[bridgman]

I agree with your point about timeliness but I disagree strongly with your interpretation of the current situation. You are assuming that the current state (or maybe the state a few months ago) of product support relative to product introduction will continue indefinitely unless drastic changes are made.

We stopped supporting open source development some time in 2002 and re-started in 2007. In the last 15 months we have caught up with 5 years of product introductions (3xx, 4xx, 5xx) and have display/modesetting support for two more generations (6xx, 7xx) including all currently shipping products. Once we get 3d engine support out for 6xx/7xx (which is pretty close now) we will have caught up with the last 6 years of product introductions and support for future generations of GPUs should be able to come out shortly after launch.

Feel free to reserve judgement until the 6xx/7xx 3d engine support is released, but once that happens I don't think you will have much justification for arguing that there will be an ongoing, unacceptable delay between product launch and open source driver support.

[deanjo]

The good news is that the open source community does seem to be coming through. Right now probably seems like the "worst of times" from a user perspective because all of the important changes in the open source stack are just starting to come to life and if anything you are seeing a short-term reduction in performance and stability, but that will pass over the next 6 months.


And 6 months down the road the RV870 cards will be out and then the waiting game starts again.

[hdas]

Let me stick to the thread subject, by saying that this driver seems to improving each time. Just compiled the shining new 2.6.28 kernel on my Ubuntu 8.10 64-bit system and the NVidia 180.18 guns down the entire gtkperf 1000 rounds in less than 100 seconds on my notebook with 8400M GS (at one time, with 170'ish drivers, its used to be 240 seconds!):

GtkPerf 0.40 - Starting testing: Thu Dec 25 04:41:55 2008

GtkEntry - time: 0.66
GtkComboBox - time: 11.42
GtkComboBoxEntry - time: 9.40
GtkSpinButton - time: 1.65
GtkProgressBar - time: 1.84
GtkToggleButton - time: 1.69
GtkCheckButton - time: 0.72
GtkRadioButton - time: 1.81
GtkTextView - Add text - time: 51.36
GtkTextView - Scroll - time: 4.99
GtkDrawingArea - Lines - time: 3.20
GtkDrawingArea - Circles - time: 4.18
GtkDrawingArea - Text - time: 5.25
GtkDrawingArea - Pixbufs - time: 0.73
---
Total time: 98.91

Regarding VDPAU, I running into a known issue that my video card is running out of VRAM when I am on dual monitor and playing 1080i, but works fine when only running my notebook display. Meanwhile, 3d games like Doom3 run flawlessly as ever. Overall, its holiday time! Thanks NVidia!

[DeepDayze]

Let me stick to the thread subject, by saying that this driver seems to improving each time. Just compiled the shining new 2.6.28 kernel on my Ubuntu 8.10 64-bit system and the NVidia 180.18 guns down the entire gtkperf 1000 rounds in less than 100 seconds on my notebook with 8400M GS (at one time, with 170'ish drivers, its used to be 240 seconds!):

Regarding VDPAU, I running into a known issue that my video card is running out of VRAM when I am on dual monitor and playing 1080i, but works fine when only running my notebook display. Meanwhile, 3d games like Doom3 run flawlessly as ever. Overall, its holiday time! Thanks NVidia!

Is there a bug report for that? How much memory your card have?

[bulletxt]

Feel free to reserve judgement until the 6xx/7xx 3d engine support is released, but once that happens I don't think you will have much justification for arguing that there will be an ongoing, unacceptable delay between product launch and open source driver support.

I will shut up only when I see AMD cards working like NVIDIA. at that point, not only I will drink 3 bottles of champaigne, but I will also suggest to everyone to buy AMD gpu's since their drivers work out of the box and are open source. But I think I should stop my dream here. Let's see, let's see..

[_txf_]

And 6 months down the road the RV870 cards will be out and then the waiting game starts again.

but programing for them shouldn't be very different from 6xx and 7xx. Possibly for more advanced features there will be changes (which won't be used by the foss driver). I suspect that directx 10 is doing foss a favor here and the fact that more and more general purpose computing is forcing a certain amount of "homogenization" of the tech.

[deanjo]

Is there a bug report for that? How much memory your card have?

Running out of vram isn't a bug. 256 Meg cards simply run out.

[bridgman]

And 6 months down the road the RV870 cards will be out and then the waiting game starts again.

but programing for them shouldn't be very different from 6xx and 7xx. Possibly for more advanced features there will be changes (which won't be used by the foss driver).

Bingo. One of the big changes between 5xx and 6xx was virtualizing a good chunk of the hardware; partly having more stuff stored in video memory so the driver developers didn't need to worry about on-chip storage, and partly putting a layer of abstraction between the driver programming model and the actual hw implementation.

This really helped going from 6xx to 7xx, for example; the underlying hardware is quite different on 7xx but the acceleration code didn't have to change much at all. On the other hand it sure makes initial bringup and troubleshooting harder, ask any of the developers involved so far.

For future parts, the good news is that now we are largely "caught up" with the last 6 years of hardwware so we can now start to work on open source docs and code while the chip is being developed, which means we have access to the mega-$$ hardware emulators and can see what is going on inside the chip, not just what the programming model tells you. We had to use the emulators a bit getting 6xx/7xx 3d running; the funny part was that we ended up doing the debug on an as-yet-unreleased GPU because that's what happened to be loaded in the emulator.

EDIT - why do all the really interesting AMD/ATI discussions happen in NVidia threads ? Maybe we should take this outside :D

[deanjo]

Bingo. One of the big changes between 5xx and 6xx was virtualizing a good chunk of the hardware; partly having more stuff stored in video memory so the driver developers didn't need to worry about on-chip storage, and partly putting a layer of abstraction between the driver programming model and the actual hw implementation.

This really helped going from 6xx to 7xx, for example; the underlying hardware is quite different on 7xx but the acceleration code didn't have to change much at all. On the other hand it sure makes initial bringup and troubleshooting harder, ask any of the developers involved so far.

For future parts, the good news is that now we are largely "caught up" with the last 6 years of hardwware so we can now start to work on open source docs and code while the chip is being developed, which means we have access to the mega-$$ hardware emulators and can see what is going on inside the chip, not just what the programming model tells you. We had to use the emulators a bit getting 6xx/7xx 3d running; the funny part was that we ended up doing the debug on an as-yet-unreleased GPU because that's what happened to be loaded in the emulator.

EDIT - why do all the really interesting AMD/ATI discussions happen in NVidia threads ? Maybe we should take this outside :D

So your telling me that within 6 months of the RV870 release you will have Crossfire support, current openGL level support, accelerated video support and have the same level of performance as the windows drivers?

[bridgman]

So your telling me that within 6 months of the RV870 release you will have Crossfire support, current openGL level support, accelerated video support and have the same level of performance as the windows drivers?

Sure, but I think we were talking about the open source drivers not the proprietary ones. If you want to match the performance and features of the proprietary Windows drivers I expect you will need to use the proprietary Linux drivers. I believe that will apply to all vendors, not just to us.

Within six months of next generation GPU launch I expect that open source driver support will have all of the capabilities supported by the common open source driver code base, whatever those happen to be. I expect that will include :

- GL2.x support -- not sure what the plans are for GL 3.0 in the open drivers, I expect OpenCL will be higher priority

- accelerated video (probably including some decode accel)

- 2d performance comparable to the best of the open drivers today

- considerably higher 3d performance relative to Windows than the open drivers offer today

As I have mentioned before, we do not currently plan to provide open source support for the proprietary video decoding hardware (UVD) but will investigate whether it is possible. That said, a lot of the decode overhead even for H.264 and VC-1 is spent in functions which can easily be done on the GPU (mocomp, filtering), so I think you will see a fair amount of progress in decode acceleration over the next year whether or not anyone opens up the full decode hw.

[DeepDayze]

one thing I still find with the 180.xx drivers is that flash vids play VERY slow...seems to be a negative interaction between flash and the nvidia driver. The 173.xx series sees to be OK

[deanjo]

Sure, but I think we were talking about the open source drivers not the proprietary ones. If you want to match the performance and features of the proprietary Windows drivers I expect you will need to use the proprietary Linux drivers. I believe that will continue to apply to all vendors, not just to us. We are not intending to replace fglrx with an open driver now or in the future.

Within six months of next generation GPU launch I expect that open source driver support will have all of the capabilities supported by the common open source driver code base, whatever those happen to be. I that will include :

- GL2.x support -- not sure what the plans are for GL 3.0 in the open drivers, I expect OpenCL will be higher priority

- accelerated video (probably including some decode accel)

- 2d performance comparable to the best of the open drivers today

- considerably higher 3d performance relative to Windows than the open drivers offer today

As I have mentioned before, we do not currently plan to provide open source support for the proprietary video decoding hardware (UVD) but will investigate whether it is possible. That said, a lot of the decode overhead even for H.264 and VC-1 is spent in functions which can easily be done on the GPU (mocomp, filtering), so I think you will see a fair amount of progress in decode acceleration over the next year whether or not anyone opens up the full decode hw.

I am talking about the opensource drivers. Judging by your reply the answer is that the opensource drivers will not take full advantage of the hardware's capability. Therefore blobs are the only solution if you want to take full advantage of the hardware. Case and point, if you want limited features and slower performance you go with the opensource alternatives. If you want full feature set , best performance and near same day support, you go blob. It's the features and performance that cause people to buy newer cards, if those features are not supported then why upgrade when you are a foss die hard and the performance and features are going to be crippled by using the foss drivers?

[Kjella]

I am talking about the opensource drivers. Judging by your reply the answer is that the opensource drivers will not take full advantage of the hardware's capability. Therefore blobs are the only solution if you want to take full advantage of the hardware.

It's not reasonable to assume that highly optimized drivers written by a team working closely with the hardware designers will be beaten just like that, if it was then somebody should have been fired. I'd say they would have come far if they have full working acceleration in six months - not optimized and all that but stable, visually correct and within an order of magnitude of the proprietary drivers on all fronts and maybe half performance on average.

It's important to get a little perspective on where we are too - without acceleration many things run ungodly slow, where even a very naive one would probably improve performance by a few orders of magnitude. The first order of business is to make them playable under open drivers at all, then you can start optimizing. There's a lot of slightly older games that could be made playable that aren't. It sure beats a big nothing.

[deanjo]

It's not reasonable to assume that highly optimized drivers written by a team working closely with the hardware designers will be beaten just like that, if it was then somebody should have been fired. I'd say they would have come far if they have full working acceleration in six months - not optimized and all that but stable, visually correct and within an order of magnitude of the proprietary drivers on all fronts and maybe half performance on average.

It's important to get a little perspective on where we are too - without acceleration many things run ungodly slow, where even a very naive one would probably improve performance by a few orders of magnitude. The first order of business is to make them playable under open drivers at all, then you can start optimizing. There's a lot of slightly older games that could be made playable that aren't. It sure beats a big nothing.

Again your just re-enforcing my point:

If you want basic support that maybe as good as the blobs in stability and are satisfied feature loss and slower performance on average then maybe opensource is an alternative.

If you want advanced support and features with great performance that is on par with other OS's, stability because of complete documentation and the close working relationship with their engineers, then the blobs will always have a huge advantage over their foss counterparts thus why everyone claiming "just give us the docs because we can do better" and telling the companies to "scew off and abandon the blobs" are delusional. People upgrade cards for better performance because their present solution is "tapped out". Opensource drivers are the limiting factor when used on a piece of hardware, with the blobs it's usually a case of the hardware has reached it's limits, not the blobs.

[bridgman]

I think there is a place for both. The open source drivers will (of necessity) be smaller and simpler than the blobs because of the huge resource differential -- but simplicity brings a lot of advantages as well. I see the open source drivers potentially being more stable than any of the proprietary drivers, and they will certainly adapt more quickly to changes in kernel and graphics framework.

Modern graphics cards are *really* fast, to the point where it is pretty hard to get GPU-limited on a high end card under Linux unless you run the largest possible screen and crank up all of the visual effects. Our architects figure that the open source 3D drivers should be able to run around 50-60% as fast as the proprietary drivers just by being "clean and elegant", ie without a big investment in performance tuning. A lot of users won't care about that difference.

2D performance is already driven more by enhancements in the server than in the driver (so the open source drivers are often faster), and we expect that to continue. Getting the 3D drivers to the 50-60% performance level will require work at all levels of the 3D stack, but between Gallium3D, GEM and the ongoing command submission restructuring effort most of the key areas are being addressed now.

I agree with you completely that getting rid of the blobs is not practical if we want to address the entire Linux market, but there are a lot of benefits to offering a fairly full-featured open source solution as well.