Hi Martin, Martin Spott writes: > Especially the mess with NVidia's drivers is the manufacturer's fault. > ATI at least _tries_ to conform with the standards proposed by the DRI. > With ATI you can copy the DRI driver module and the kernel module > (after tweaking the build script) to the appropriate places. > With NVidia (at least the last time I looked at their drivers) you have > to:
I will address these points, since they are mostly false and/or misleading. > a) Unload the kernel's GART module during the autodetection and load > NVidia's special kernel module, Nvidia's kernel module does have an AGP driver, but it is smart enough to not activate this portion of the driver if the linux GART module is already there. As far as I know it has always been this way. Depending on your system, one or the other may work better for you though, so the nvidia readme encourages try the "other" one if you have problems with the first. And nvidia does provide full source for their own kernel module. > b) replace the OpenGL libraries, Yes this is allowed. Unfortunately XFree86/Mesa don't (or at least didn't) put the opengl libs where the linux standard said they should, nvidia did. That causes a huge mess if you have multiple opengl libs on your system and you aren't sure which one's your app is picking up. Like I say, this was a big mess before nvidia got involved. Especially consider that prior to that, the only way to do opengl in a window on linux was with a voodoo3 card. To get this running, you pretty much had to grab XFree86 cvs tree and build it yourself. This was 100x harder to get running than the approach nvidia used. > c) run a special X Server. Nvidia gives you a new driver (nvidia vs. nv) for your X server, but you have never needed a special X server. > _This_ is what I'd call a huge mess. I will continue to assert that what nvidia was trying to plug into was already a huge mess in terms of supporting hardware accelerated opengl within XFree86. This is a hard problem and many smart people were struggling with it. They came up with a reasonable solution, DRI, but it just wasn't ready to go when nvidia was ready to go. You at least have to credit nvidia for going out on a bit of a limb at the time to even support linux. This was *huge* for people who had been struggling along with voodoo1,2,3 cards and were living with very frustrating bugs in Mesa or in mesa's interface to the voodoo cards. Suddenly along came nvidia and we were able to get fast and correct rendering for the first time ever under linux. This was huge! I personally am very greatful to nvidia for this. They made linux a viable 3d platform. > I don't like ATI's approach either but these guys show that things > could have been done at least in a significant better way. Yes, > there was no 3D standard for Linux when 3D boards for PeeCees became > affordable. But NVidia's driver effort was very late as well. They > _would_ have had the chance to stick to DRI standards but they > simply don't have any interest into doing anything different from > "their own way". nvidia's effort was a *lot* earlier than ATI's. Yes there was some disappointment that they didn't follow the DRI standards, but I think you can make a plausible argument that the DRI standard was not fully fleshed out when nvidia started developing their linux drivers. I still don't see how any of this rises to the level of causing someone to boycott their company. And as you say, you are running hp, sgi, and ibm machines. I can't imagine every byte of code on those machines is fully open source. If you are actually running all open source operating systems and drivers on all these machines, then you are definitely not doing any opengl on those machines. Again, I see absolutely no problem with running the vendor's os, or linux or whatever you want on those machines, but I find it a bit odd that you are arguing so strongly for others to not run any proprietary code or drivers, when clearly you must be doing this yourself. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
