This is an initial FreeBSD beta driver for 2D and OpenGL for FreeBSD. It requires FreeBSD -STABLE, version 4.7 or later. It can run single threaded aplications even in linux compatability mode.
Nvidia Releases OpenGL Graphics Drivers for FreeBSD
Submitted by HmJ 2002-11-08 FreeBSD 15 Comments
Nvidia surpised me!
The NVIDIA drivers don’t just help 3D performance. 2D performance is *much* improved for the native X drivers, in particular because the nvidia driver seems to accelerated XRender extension which is used for drawing fancy text and stuff in modern desktop environments. Rumor has it that these drivers also work (with some massaging) on 5.0-CURRENT. It will be *very* interesting to see which one, FreeBSD 5.0 or Linux 2.6 takes the crown as best x86 compatible desktop UNIX (see, I can be politically correct too! I could have just said “best desktop OS.”)
Note> I’d just like to give a plug to the Gentoo developer who maintains the NVIDIA kernel driver. Great job in building the patches for the 2.5 development kernel into Portage! What is a real nerd to do when even hackery like this is automagically taken care of by his distro?!!
Could you elaborate on this: It can run single threaded applications even in linux compatability mode. ?
Does this mean that multi-threaded linux apps fail under FBSD4.6, or that they don’t work with the new driver, or what? I’m a non-FBSD/Linux cross-user so I’m trying to gague the goodness of this statement. (for the record, I prefer OpenBSD for my unix needs, which is why I don’t know this stuff )
And could Rayiner clear this up: I’d just like to give a plug to the Gentoo developer who maintains the NVIDIA kernel driver
Does this mean that Gentoo is involved with nVidia’s driver development, or that they maintain their own OSS nVidia driver?
Now if only ATI started to support Linux as nVidia does. They act like Linux doesn’t exist. Come on ATI wake up and do something.
Err, I meant the ebuild for the NVIDIA driver. Basically the driver package.
>Now if only ATI started to support Linux as nVidia does.
I guess you haven’t used the Linux nvidia drivers, or you would have said “Now if only ATI started to support Linux.”
The nvidia drivers aren’t very good. For one their closed source, which wouldn’t be a big problem, except that the drivers suck. I can replicate crashes because of them, and all kinds of wierd quirks, like making my monitor turn black and white, but with blue rather than white. I don’t think they even take the the drivers seriously, in the Makefile on one of the versions I got a while back, all through the Makefile were retarted comments that just made the drivers seem unproffessional. like above one line of code
#This line is just wrong: remove it!
so anyway, if ati’s gonna release drivers for linux, the way they shouldn’t do it, is like nvidia.
While ATI may not be activly devloping linux drivers (or FBSD) with paid employees, they will fully release the specs to interested parties, something NVida are unwilling to do.
I have also heard that some ATI engineers work on linux drivers in their spare time, but I don’t know how true this is.
I personally don’t know which I prefer, I guess in the short term binary drivers are more useful than non finished open source drivers. But I would imagine that as the source drivers become more mature, their advantage will be shown.
If these Nvidia drviers were open source, I imagine OpenBSD an NetBSD (and any other BSD im not aware of) could all port them really easily.
nvidia’s linux drivers have worked very well for me… i had a few problems with crashes early on… but newer versions and more experience on my part with tweaking and they started behaving quite well
The NVIDIA drivers, for me, have been extremely stable. I’ve used them on the following configurations:
1) P2-300 on Intel 440LX motherboard with a RivaTNT and GeForce2 MX.
2) Athlon XP 1700 on SiS 735 motherboard with GeForce2 MX and Riva TNT.
3) Pentium 4 2000 on Intel 845M motherboard with GeForce4Go.
The only time I’ve ever had the NVIDIA drivers lock up on me on any of those configurations was last week when I edited the devfs code to get them to compile on 2.5.44. I’m running them now on 2.5.46 using patches bundled with Gentoo, and they’re still rock solid stable. They’re also extremely fast, just as fast as the Windows builds (now that page-flipping is supported). It’s not ideal that they’re closed source, but remember, an OpenGL driver is an entire implementation of OpenGL (everything from user-level OpenGL calls down to hardware manipulation). That’s a whole lot of code. Not only is part of that code licensed from other places, but the upper (device-independent) layers of that code would be very helpful to ATI, whose drivers (on any platform) are sub-par.
You are right, nVidia had so many driver releases and now their driver is relatively mature, supported across various platforms; that can’t be said for display cards from other companies, nor the frequency of their often releases.
The only problem I have with nVidia’s drivers is when I log out of KDE, and am waiting for KDM to come back up, I get some garbage at the top of the screen. It doesn’t matter at all tho. Otherwise, everything is perfect. Plus, 3D framerates tend to be about 10% higher in Linux than Windows when running the same code (the only things I’ve tried in Linux tho are bzflag and some homework assignments I had for a class I was taking in OpenGL).
I think how poorly the nvidia drivers are working for me is due a lot to my configuration. The card that I am using is a leadtek twinview, and I have two monitors and a tv hooked up to it. All the problems that I mentioned earlier are experienced when using two monitors. With multiple versions of the driver, I can repeatedly lock up the whole linux system by simply starting X, ctrl + alt + backspacing, and repeating a few times..no matter at what pace I do this, eventually the thing will crash either when starting X or ctrl + alt + backspacing. Also to get the black and blue screen, all I have to do is reboot, and my second head goes black and blue when X starts. That too has happened with multiple driver versions, and never happened with the windows drivers when I was dual booting. The only way to keep it from happening is when restarting I actually have to shut off the computer, and then wait a couple seconds and start it again. Those might only happen with a dual head setup, but there are other problems with the nvidia drivers that are issues on all systems. The manner that the XF86Config is constructed alone is pretty bad. The nvidia driver handles metamodes, dual heads, and some other things in the XF86Config, in a completely unstandard way that just generally causes confusion and is pointless. Also, the nvidia driver has to have a kernel module. Not so bad if you don’t mind running a modular kernel, but if you want to go completely monolithic, you can’t do it, and then have to add module support to the kernel, just because of the nvidia driver. My experience with the nvidia drivers over the last year has been nothing but a hastle. I like the card’s opengl performance, but with drivers of this quality, it’s almost not worth it.
The problem you’re having seems to indicate a resource leek of some sort in the kernel driver (probably related to the relatively immature TwinView code), ie: at shut-down, it’s not entirely freeing up the resources it allocated at startup. That said, you shouldn’t be ctrl + alt + backspacing to shutdown X. It’s meant for a panic quit, and you can expect that things won’t cleanup right. KDE, for example, will trash certain config files if you ctrl-alt-backspace at the wrong time. As for the XF86Config thing, there is a reason why the NVIDIA driver has non-standard bits. There are a lot of features that X simply doesn’t have any knowledge of, NVIDIA doesn’t have any choice other than to put those unrelated things into it’s own config section. TwinView for example, is different from Xinerama (the X multihead extension). Xinerama can’t be implemented on the GeForce while still allowing OpenGL acceleration for all screens, so NVIDIA implemented TwinView instead. TwinView configuration on Windows is also set apart from the standard Windows multi-head configuration. Lastly, all OpenGL cards need a kernel driver. The userspace driver constructs command lists, but the kernel driver is needed to setup the DMA commands to the graphics card. Now you can compile the DRI drivers entirely into the kernel, but only because they come in source form. Besides, it’s not really a weakness not being able to build a completely monolithic kernel. It’s not like you get any performance advantage. The way the kernel is linked is not like how a DLL is linked. Normal function calls are bound directly, instead of through an indirect jump. Calling code within the kernel is just as fast as calling code in a module. Also, most code in drivers is called through a table of function pointers (basically a C++ v-table implemented in C) anyway, so most driver calls (compiled-in or modular) are indirect calls. Lastly, there is talk from Linus about wanting to get rid of statically compiled drivers, because it makes configuration more complicated, and is ultimately unnecessary.
I have a problem with these drivers on FreeBSD 4.7-STABLE and a G-Force 2 MX video card. When X is starting I see nVidia graphics logo and then computers hangs up (the keyboard stops responding and so on). What should I do, to get these drivers work for me?
There are some reports that updating XFree86 to the latest version can solve the problems, for more information, you can check out this thread from bsdforums.org: