View Full Version : NVidia should STOP supporting Linux
I've been a Linux user for 13 years. I had always avoided nvidia graphics cards because of the binary only drivers. I finally broke down and decided to give the card a try. But my Linux computer uses a kernel with Xen compiled in, a virtualization technology that lets my one computer run a number of different instances of Linux (and soon, Windows once the next generation of Intel and AMD chips with Pacifica virtualization technology are available) which allows me to consolidate a bunch of different servers into one box and make much better use of the hardware. It's more like a mainframe with efficient resource sharing. And the nvidia binary drivers won't work under a Xen kernel. I found this out after a day of trying to get the nvidia drivers to compile a custom interface for my kernel. I talked to the Xen developers and they confirmed my worst fears: It's just not going to work. If these drivers were distributed with the rest of the kernel like everything else this would have been a piece of cake. I have just returned from the store where I returned my Nvidia card. I should have known better than to think binary kernel modules would work out. I wish nvidia would either just GPL the drivers (it's the hardware that makes them money anyway isn't it?) or stop supporting Linux altogether so people would stop wasting time trying to get this stuff working because unless you have anything other than the simplest of systems it's going to drive you nuts. I know I'll never give nvidia another try until the driver problem is properly fixed.
Easy solution: just switch to FreeBSD/amd64 :D
So what's the deal with SMP safety in the latest drivers? Is that indeed broken? Are the lock statements in the binary code or the source wrapper?
I wish nvidia would either just GPL the drivers (it's the hardware that makes them money anyway isn't it?) they have already stated that they would not do this because it would compremise system securty.... i dont know if this is true or not but im just repeating what they said...
No, it would allow everybody to see what level of optimization is in the drivers. A large part of the work of making a fast gaming card is figuring out what work you can skip without a human possibly noting it. A large part of this is done in the driver, not the hardware. Opening the drivers would mean that first the competitors can see how you do it and what the result of your research was, and that there will be a huge zealot backslash about all the things that the driver skips and very suddenly people start noticing.
That is all fine.
However, while I did buy NVidia's reasons not to opensource the graphics cards drivers I also think the fact that NForce SATA and GbE are also not documented to driver writers clearly shows that there is a large part of company politics involved here.
While I have no problem buying a complicated graphics card with no opensource drivers when the competitors don't give hardware docs either, I really don't see why I should trust a company which does not document hardware that the competitiors do document. And since it is the same company the SATA/GbE issue now makes me seriously considering buying other graphics cards in the future, too. I already avoid the mainboards.
Also, lets not forget that while both ATI and NVidia document enough of their modern cards to do 2D, the ATI driver does support TV and dual-head and the NVidia driver does not. The absense of power management in the nv driver also hurts pretty badly, leading to high power consumption while idle in 2D mode.
I bought a pretty good number of $200-$500 cards lately, all NVidia. If NVidia wants my continued business they will have to show some sign of interest in my business, which would be one or more of Provide documentation for SATA and GbE and other NF devices
Straighten up ACPI on NF boards
Document more of the 2D part of the cards to enable TV out, dual head and power management in the OpenSource "nv" 2D driver
Fix a bug or two in the Linux driver
Linux SLI
Make absolutely sure the drivers are SMP-safe. It's the age of dual-core, dammit
Any one or more of these would put some faith back into me that NVidia is still a cool company. If they want my part of their core business, even while keeping the 3D driver closed, that would come in handy.
I wish nvidia would either just GPL the drivers (it's the hardware that makes them money anyway isn't it?)
It's the hardware, but hardware won't do any good without proper drivers to access it. And like already discussed, writing decent drivers takes great deal of effort in algorithm research -- very valuable knowledge. Most companies don't like sharing their secrets just like that.
Apart from that, GPLing virtually any commercial product isn't exactly straightforward; most of the time there are bits and parts from your business partner or whatever 3rd-party who is unwilling to share their itellectual property under GPL. To put it brief: even if nVidia wanted to GPL their drivers, they probably couldn't do it without lots of trouble.
or stop supporting Linux altogether so people would stop wasting time trying to get this stuff working
Excuse me, but that sounds slighty like "if I can't get it, nobody will" -attitude. I fully understand your point, but IMO giving people a chance to try the drivers won't really hurt anyone. It's not like anyone would force you to buy the hardware.
I know I'll never give nvidia another try until the driver problem is properly fixed.
It's always good to know that consumers can make difference by voting with their money.
Just my two cents.
I've been a Linux user for 13 years. I had always avoided nvidia graphics cards because of the binary only drivers. I finally broke down and decided to give the card a try. But my Linux computer uses a kernel with Xen compiled in, a virtualization technology that lets my one computer run a number of different instances of Linux (and soon, Windows once the next generation of Intel and AMD chips with Pacifica virtualization technology are available) which allows me to consolidate a bunch of different servers into one box and make much better use of the hardware. It's more like a mainframe with efficient resource sharing. And the nvidia binary drivers won't work under a Xen kernel. I found this out after a day of trying to get the nvidia drivers to compile a custom interface for my kernel. I talked to the Xen developers and they confirmed my worst fears: It's just not going to work. If these drivers were distributed with the rest of the kernel like everything else this would have been a piece of cake. I have just returned from the store where I returned my Nvidia card. I should have known better than to think binary kernel modules would work out. I wish nvidia would either just GPL the drivers (it's the hardware that makes them money anyway isn't it?) or stop supporting Linux altogether so people would stop wasting time trying to get this stuff working because unless you have anything other than the simplest of systems it's going to drive you nuts. I know I'll never give nvidia another try until the driver problem is properly fixed.
You look to me like someone who can't get the driver to work and yells at nvidia because of his own fault. For most people, the driver works, so stopping the linux drivers would be the worst thing NVidia could do.
Also, you didn't really investigate into that: The kernel module is open source. Only the X11 driver is closed source. I doubt that you even really looked at the driver! I even doubt that you tried to install it, otherwise you would have seen that the kernel module gets compiled!
Dragoran
10-09-05, 07:34 AM
The kernel module is open source. Only the X11 driver is closed source. I doubt that you even really looked at the driver! I even doubt that you tried to install it, otherwise you would have seen that the kernel module gets compiled!
only a part of the kernel module gets compiled. This parts then loads the binary part (nv-driver.o)
But it's still open enough to port it to NetBSD, which is way different from the Linux Kernel. So porting it to Xen should be even easier than to NetBSD.
brian33x51
10-10-05, 02:18 PM
Easy solution: just switch to FreeBSD/amd64 :D
So what's the deal with SMP safety in the latest drivers? Is that indeed broken? Are the lock statements in the binary code or the source wrapper?
Umm..how is this gonig to fix Xen?
Or freebsd is able to run everything in the world?
Ugh I hate trolls...
wshadow
10-10-05, 03:55 PM
just a quick question...Has there been any major games ever that have been released on disc with a linux version?
Has there been any major games ever that have been released on disc with a linux version?
Does UT2004 count?
wshadow
10-10-05, 05:47 PM
yes that would, any other ones?
I disagree, if it works, leave it. The NVIDIA drivers have been working for me since I started using Linux 2 years ago. I'm pretty happy. Although, I'm not happy that some games running on Cedega don't render properly in OpenGL 2 mode.
gnutux
The nvidia driver works great. Yes in a perfect world they would be open sourced but it isnt. I have never had a problem with the nvidia driver since I started using it with a geforce 2 mx. There are open source drivers that work fine for most video cards(nvidia, ati, etc) avaible in the kernel. The only down side of there drivers is that OpenGL hardware acceleration isnt that great. It would be a very sad day if nvidia ever stopped supporting Linux, infact shocking becasue I remember reading nvidia say that 30% of there customers are running Linux.
I've been a Linux user for 13 years. I had always avoided nvidia graphics cards because of the binary only drivers. I finally broke down and decided to give the card a try. But my Linux computer uses a kernel with Xen compiled in, a virtualization technology that lets my one computer run a number of different instances of Linux (and soon, Windows once the next generation of Intel and AMD chips with Pacifica virtualization technology are available) which allows me to consolidate a bunch of different servers into one box and make much better use of the hardware. It's more like a mainframe with efficient resource sharing. And the nvidia binary drivers won't work under a Xen kernel. I found this out after a day of trying to get the nvidia drivers to compile a custom interface for my kernel. I talked to the Xen developers and they confirmed my worst fears: It's just not going to work. If these drivers were distributed with the rest of the kernel like everything else this would have been a piece of cake. I have just returned from the store where I returned my Nvidia card. I should have known better than to think binary kernel modules would work out. I wish nvidia would either just GPL the drivers (it's the hardware that makes them money anyway isn't it?) or stop supporting Linux altogether so people would stop wasting time trying to get this stuff working because unless you have anything other than the simplest of systems it's going to drive you nuts. I know I'll never give nvidia another try until the driver problem is properly fixed.
"Hello my name is Bill Gates."
Son Goku
10-22-05, 08:03 PM
Well this thread was certainly a surprise, so I clicked on it. Anyhow, a few things:
- Personally, I don't buy the argument which peeps are stating that nVidia had said, that GPLing the drivers would make the systems (read as people's computers) less secure. The graphics card driver should have nothing to do with that, and given an open source operating system...I think someone fudging up on the recompilation of IP chains or something of the sort could be a more effective way to compromise system security :D Same goes for packages such as open SSL, etc...
That nVidia doesn't want people to see where they have "driver specific optomizations", or what others would call cheats where it, for instance, looks for 3D Mark and then runs sub-optimal IQ to get more points sounds a lot more on the money IMO... I'm sure instances of this (both in ATI's as well as nVidia's drivers) which have become public knowledge are probably just the tip of the ice burg...
- Ultimately, from the users perspective, as opposed to the marketers perspective...if the driver source being open source resulted in more intense competition between ATI and nVidia to further optomize their drivers, knowing full well something they add today could be added by a competitor tomarrow; we the users would win. And a "this will only help X synthetic benchmark 'trick'" wouldn't cut it as people would more readily know. Again, good for the user who wants to know what real gaming performance they'll see when going to the store and considering which card; not how something can be optimized soley for a benchmark alone. Hardware improvements, and driver coding improvements that effect all apps would really be the only way to do it.
- As to competitors, it might not be an above board and widely talked about matter, but many times the competitor has a better idea of what a company is doing then the public. Sometimes, (if a competitor is reverse engineering a product), they might know something the manufacturer hadn't figured out yet, such as occured with the F00F bug in the original Pentium processor.
http://www.x86.org/errata/dec97/f00fbug.htm
Within a day or so, I called another colleague who used to work at one of Intel's competitors. I told him about the bug. To which he responded: "yeah, I found that bug about a year and a half ago." If this bug was so easy for one or more of Intel's competitors to find, why hadn't they ever discovered it, disclosed it, or quietly fixed it? The answers lie in the nature of Intel's competition, and Intel's design verification methodology.
It is quite natural for Intel's competition to find bugs like this. They are in the microprocessor cloning business. Therefore, they must write programs that scan the entire opcode space in search of hidden and undocumented instructions. Invalid opcodes come in many forms. The most obvious form is an undefined instruction -- an opcode that doesn't map to any instruction. These opcodes are easy to scan programmatically. Other invalid opcodes are actually invalid encodings of valid instructions. These invalid encodings are often times overlooked when scanning for undefined instructions.
Intel's competition must find these instructions. Therefore they write programs that scan the entire invalid opcode space. A well-designed program will test all of the invalid opcodes and invalid encodings of valid opcodes. This is how my colleague found this bug 18 months ago. Even though he knew about the bug, his knowledge was the intellectual property of his company. Therefore he would have been prohibited from warning the Internet community, even if he wanted to warn them.
Reverse engineering, along with de-compiling a program is one of those "dirty little things" that many know about, though fewer will mention. It isn't something that isn't done, however... In some of the computer programming classes I have taken at uni, when the subject had come up for instance, the topic came down to a "yeah, I know what that is, though the university forbids us from discussing it...", a quick mention and attempt to get off the topic prompto...
I doubt that AMD would say that they've reverse engineered Intel's processors in an attempt to make sure their processor remains compatible with changes Intel's made to x86; but logic would dictate that if they aren't going to trust Intel to document everything for them, they will. That CPUid found the 96-bit unique identifier in my Athlon Tbird 1 GHz after Intel introduced this (and soon after removed it), I found sorta odd. Always figured AMD copied the circuitry over to the Thunderbirds, and latter when Intel removed it... AMD never officially announced adding this to their CPUs.
- How many games have been cross compiled to Linux isn't the entire answer. Someone who wants to game on Linux, would sort of need something like transgaming (kedega, or winex), or some other such addition to continue playing Windows games.
Even with Wine or transgaming however, one would still need drivers to the graphics card with hardware accelerated OGL support, for the D3D API calls to be mapped out to OGL calls for the game to play...
- Disbanding Linux driver support altogether would seem a little like throwing the baby out with the bathwater here. Perhaps a mention of what problems are being run into could result in someone who had a similar problem having a fix in mind.
Soul-Crusher
10-25-05, 04:19 AM
Sorry to beat on a dead horse, but I thought I'd bring up a few points. But before I do, I just want to reveal my bias in favor of nVidia since I've been using their proprietary drivers with great success since even the first public release over four years ago. I was using a TNT2 Ultra at the time.
But my Linux computer uses a kernel with Xen compiled in, a virtualization technology that lets my one computer run a number of different instances of Linux (and soon, Windows once the next generation of Intel and AMD chips with Pacifica virtualization technology are available) which allows me to consolidate a bunch of different servers into one box and make much better use of the hardware.
Virtualization technology will soon become extremely important to nVidia, rest assured. However, you should be aware that not all hypervisors are alike. Xen is a type 1 hypervisor, VMWare is a type 2 hypervisor. I think Microsoft's hypervisor will also be type 2, but I'm not entirely certain on that. I do know that it will be quite a bit different from Xen. They are pretty drastically different architectures--They handle I/O and interrupts much differently. Ideally, the hypervisor should abstract the differences and we should see them only in the performance of the apps that run on top of them, not in the coding. However, this is rarely the case and I'm not optimistic that nVidia will go out of their way to support Xen right off the bat (Although I'd be very happy if they did).
And the nvidia binary drivers won't work under a Xen kernel.
Nope, just as the nVidia binary drivers probably won't work for a kernel configured for Alpha or ARM or some other architecture. Xen requires an extremely invasive kernel patch. While it's due to be merged into the main Linux repository, it's met a fair amount of resistence because of this.
There are a number of important kernel patches out there that haven't made it into the kernel. Everything from schedulers for the embedded folks to experimental filesystems to lesser-known architectures to distributed processing for clusters. Binary drivers will probably not work with the vast majority of these, and there's no reason nVidia should invest the time necessary to fix it for all possible combinations of weirdo systems, especially at the cost of performance (Performance is everything in graphics). Believe me, I recognize the importance Xen has for Linux. Heck, you can see my name in a small part of the source code. However, I don't think it's in nVidia's interest at this time to support something that hasn't even made it into the kernel yet.
If these drivers were distributed with the rest of the kernel like everything else this would have been a piece of cake.
And you're basing this on what assumption? It's been known that the nVidia module does some nasty things in kernel space, which is why a lot of kernel hackers don't like it. For most people, it works.
I should have known better than to think binary kernel modules would work out.
And you know of a better option? No graphics company is particularly friendly to open source developers. Don't believe me? Think ATi is the solution? Check this thread (http://www.nvnews.net/vbulletin/showthread.php?t=58591). There is no love affair going on between anyone in the OSS crowd and ATi. While it may be limited, at least nVidia's binary driver works for most people. And for now, that beats the pants off the competition.
I wish nvidia would either just GPL the drivers (it's the hardware that makes them money anyway isn't it?) or stop supporting Linux altogether so people would stop wasting time trying to get this stuff working because unless you have anything other than the simplest of systems it's going to drive you nuts.
Stop being selfish--Not everyone runs a weird architecture on their desktops. Some of us actually like to have a stable system running useful applications, even if they are simple little things like Xorg with nice effects or games like Quake 4.
Living in the GNU/Linux world is a double-edged sword right now. On the one hand, you can audit nearly all components of your system freely and thoroughly. On the other hand, if you exercise freedoms such as applying experimental code (Xen) to your kernel, then you can get burned on support. Heck, even the transition from x86 to x86-64 took a while for all the kinks to get worked out.
And yes, nVidia is a hardware company. However, drivers can be very closely tied in with hardware design and, as others have already pointed out, can contain trade secrets. Believe it or not, there are companies out there who create products that work with Linux but don't necessarily share the GNU philosophy of sharing every bit of knowledge, especially when that can give the competition a leg up. Furthermore, most graphics cards have utilize third party add-ons such as media encoders/decoders which complicates any attempt to open source the driver. Also, it could just be that company X (ATi?) has a patent on something that nVidia developed independently which could make nVidia vulnerable to lawsuits (Think of what happened with Ford's hybrid technology and Toyota's hybrid technology). I'm sure there are more reasons, and I'm sure that none of them would go smoothly with RMS's vision of the world.
I know I'll never give nvidia another try until the driver problem is properly fixed.
Understandable. Fortunately, it's not like anyone is cramming this driver down your throat and telling you that you have to change how you run your system.
lynedavid
10-25-05, 06:28 PM
I agree with Soul-Crusher entirely.
connyosis
10-25-05, 07:51 PM
I wish nvidia would either just GPL the drivers (it's the hardware that makes them money anyway isn't it?) or stop supporting Linux altogether so people would stop wasting time trying to get this stuff working because unless you have anything other than the simplest of systems it's going to drive you nuts. I know I'll never give nvidia another try until the driver problem is properly fixed.
Soo, let me get this straight. You didn't get the driver working so everyone that did should suffer because of this? Oh, ok.
this is the dumbest thing i've ever heard. why not just suggest to nvidia to support this kernel? i guess that would make far too much sense =\
Noooooooooo!
hey have you tried ATI's drivers for linux? ( after installing it on my suse 9.3 i was forced to reinstall the whole OS)
and second of all NVIDIA rocks... when it comes to linux ( well to everything:P)
and second of all Nvidia drivers are are easier to install and perform better!
i have a ATI 9200se on my linux mechine and i'm too scared to install ATI drivers because i know they will mess up everything!
i miss my GF 2 MX :(
Also most workstations which are used for rendering are running linux With nvidia QuatroFX cards!
and hey i never had problem with my nvidia cards on any linux distrs.!
Linux SLI - well there might be one... soon!
because you could make SLI btw QuatroFX cards so i think they are working on that, not sure though.
If they do that would be really cool :P
Soul-Crusher
10-28-05, 02:06 AM
this is the dumbest thing i've ever heard. why not just suggest to nvidia to support this kernel? i guess that would make far too much sense =\
Because Xen is not even in the kernel yet. It's not even in an official development kernel, like -mm or -ck or -love or whatever. Also, Xen 3.0 is due out in a few months and will have *radical* design changes from Xen 2.0. Simply put, it's not ready, at least not for official support from nVidia. They can build against the testing tree, but they're almost certainly not going to be able to run the same code on the final release. Xen is in a huge state of flux right now.
If there are some nVidia folks lurking around, however, I would love to hear if they've been toying with Xen.
hey have you tried ATI's drivers for linux? --
and second of all Nvidia drivers are are easier to install and perform better!
i have a ATI 9200se on my linux mechine and i'm too scared to install ATI drivers because i know they will mess up everything!
I have. I used to have Radeon 9700 and 9800 Pro until very recently. I no longer remember which version the first driver was (I think it was 2.8.x), but it was released only as RPM-package (for RedHat and Suse IIRC), which I had to convert to tar.gz with alien, unpack, some some files all over and compile the module. Then maybe about a year back I heard about this Flavio (http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html) guy who had written a script to download, compile and package the stuff into Debian package. Natually I started using the script. Earlier this year ATI released this fancy installer first to compile and install the drivers and later updated the installer to create packages, including packages for Debian. I never tried the first generation of the installer, but the one creating Debian packages worked flawlessly. Of course you still had to configure your X manually, although modified xfreeconfig/xorgconfig (or whatever it was called) was provided.
Anyway, I think installing ATI's proprietary drivers never was problem -- but I do have to agree that having nVidia's drivers installed is easier than having ATI's stuff in place two years ago. At least for Debian. Right now I'd prefer having ATI's installer for nVidia as it can create packages. I'm sorry something went terribly wrong with ATI's installer for you. Did you file a bug report? (Not to mention that I have hard time believing installing the driver screwed the OS to the point where reinstalling was the only option.)
Daneel Olivaw
10-28-05, 02:08 PM
yes that would, any other ones?
Doom3
Has there been any major games ever that have been released on disc with a linux version?
Doom3
According to Wikipedia (http://en.wikipedia.org/wiki/Doom_3) (I know it's not an authority) "Doom 3 achieved gold status on July 14, 2004" and "Linux version was released on October 4". Correct me if I'm wrong, but it doesn't sound like it was on the CD.
vBulletin® v3.7.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.