NVIDIA Releases Another 180.xx Beta Driver

[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/tru...-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?

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.