Accelerated nVidia Drivers for FreeBSD

zero0w writes "nVidia has released the official OpenGL accelerated driver set for FreeBSD 4.7 STABLE. Check out the nVidia Driver page for more detail. According to the page, this release should be considered as initial beta. So don't count on it to build a day-to-day production system, yet."

Re:initial beta?

[Anonymous Coward]

No an alpha stage is when the internal company does the testing. Beta is generally given out to trusted 3rd parties and rarely the public. An alpha release will be so full of bugs that the program isnt usable. a beta release on the other hand should contain very few bugs and they shouldnt be related the actual use of the program. In the case of drivers this means it should work but playing an accellerated game or something that uses a feature like vertex shaders etc might not work as expected but 2d graphics and the default feature set should be pretty stable.

Re:well it is about time!

[dinivin]

You were saying? [nvidia.com]

Dinivin

Re:So what?

[dinivin]

I don't mean to troll, but are there any _existing_ applications / games that would benefit from this?

Sure... Every 3D linux game: Rune, heretic2, q3a, ut, ut2003, descent, hg2, sof, terminus, parsec... Should I continue?

Dinivin

Re:Source code... nVidia...

[Luke-Jr]

Well, their Linux kernel driver comes with source code (not distributable, but you can read it...) From what I hear, the only reason the GLX doesn't have sources available is because nVidia doesn't own some of the code it uses.

Re:Great! But...

[Clue4All]

Yes, games for Linux have been known to run much faster under FreeBSD's Linux emulation, even with the overhead of emulation. It's always made me wonder what Linux is doing so wrong, but I've never looked into it.

Re:Will it work with FreeBSD 5.0 and later?

[dinivin]

Rumor has it that it works with -CURRENT after you disable a check in nv-freebsd.h.

Dinivin

Re:Can I take one 2 Go?

[tgreiner]

These drivers work perfectly with GeForce2 Go cards. I'm writing this on a Dell Inspiron 8200 with GeForce2 Go.

From 'glxinfo':

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce2 MX/AGP/SSE2
OpenGL version string: 1.3.1 NVIDIA 32.03

and:

$ uname -a
FreeBSD tybalt 4.7-STABLE FreeBSD 4.7-STABLE #39: Fri Nov 8 14:42:57 CET 2002 thorsten@tybalt:/usr/src/sys/compile/TYBALT i386

Re:FACT: NVIDIA is dying

[Anonymous Coward]

You didn't mention the NV30 delay.

drivers mirrored in australia

[jason andrade]

just letting people know we've mirrored the freebsd drivers in australia at

http://planetmirror.com/pub/nvidia/drivers/freebsd / [planetmirror.com]

cheers,

-jason

Correction

[Anonymous Coward]

the readme says:

if your XF86Config has a "Device" section with a 'Driver "nv"' line, you will need to update it to 'Driver "nv"'

this should say:

if your XF86Config has a "Device" section with a 'Driver "nv"' line, you will need to update it to 'Driver "nvidia"'

--
Dreamweaver Templates
Dreamweaver Templates [dynamicexpression.com]
--

Don't count on it for a production system?

[zaqattack911]

So don't count on it to build a day-to-day production system, yet.

ermm, I don't know about you .. but I'm not playing Quake3 on my unix/bsd production systems :)

Re:Why have Nvidia done this?

[jo42]

> the number of users is [relatively] tiny

Everyone who uses Yahoo! uses FreeBSD...

Re:FreeBSD drivers instead of for Linux?

[Nothinman]

There's no "instead of" here, they have both.

OS X's userspace is from FreeBSD but the kernel is Mach, not FreeBSD.

Re:Why have Nvidia done this?

[brunes69]

The simple reason is why not? The FreeBSD and Linux drivers use the same closed source binary driver module, the only difference is in the Kernel hooks (very minor). Truth is there has been a partialy working independant NVidia FreeBSD implimentation for some time now. Most likely NVidia just used that and refined it a bit. Now that they have the kernel hook code working for both Linux and FreeBSD, maintaining them will be relatively simple.

Re:FreeBSD != Linux

[Anonymous Coward]

I think you're confusing the BSD crowd with the GPL crowd. There are many fine examples of BSD code in commercial and free binary distributions. You don't hear the BSD crowd whining about Irix.

And while we may wonder where Microsoft stuck the UC Berkeley copyright notice in Windows, we're more likely to be aware that the internet works correctly because MS did use the BSD code base to start.

Re:Linux drivers...

[dvNull]

Okay .. i dont know what HOWTO you have been reading but for redhat and Mandrake all you have to do is:

rpm -ivh NVIDIA*.src.rpm
and then
rpmbuild -bb /usr/src/redhat/SPECS/NVIDIA*.spec
and edit the XF86Config file

Or you can build directly from the tarball.

AT no time do you have to build a custom kernel to install nvidia drivers.

You had to compile a custom kernel to get xfs support and not for nvidia drivers.

dvNuLL

Re:Why

[MsGeek]

I'm going to have to bite the bullet and write a "me too" post here. I recently was exposed to the joy that is FreeBSD on the desktop. It is certainly more work to set up than your average friendly Linux distro, but once you do, IT ZOOMS. KDE 3 under FreeBSD 4.7 Stable is hella fast on my PIII 733MHz...it absolutely roars compared to KDE 3 under Red Hat 7.3. And this was before anyone could get to tuning things specifically for PIII.

The beauty of the FreeBSD codebase is how tight and fast it is. You can run it on a 486 and it doesn't struggle half as much as Linux on such a platform. You can run it on up-to-date hardware too, and it just feels like the difference between an SUV and a sportscar.

I have been involved in an effort to create a distro specifically for older computers. That's what the link to the Kawaii Project is all about. Originally the idea was Kawaii Linux, but the versatility and power of FreeBSD has opened my eyes to a potential alternative code base that could not only create a decent Open operating system for rescued old computers, but also an Open desktop operating system which could run the gamut from i486 to the fastest P4/Athlon machines.

Certainly Apple has proved that a desktop OS with a BSD under the hood is not only doable, but a great choice. Why should x86 users miss out on the fun? It's a great operating system which only needs some prettying up and simplification to be a contender on the desktop. The Kawaii Project hasn't officially decided on FreeBSD as the codebase for the project, but let's just say it's a very strong possibility that will be the way we'll go.

It's very early on yet, but here's the link: http://www.kawaiiproject.org/ [kawaiiproject.org]. BSD-heads who want in on a desktop project are encouraged to contribute ideas.

These guys are most likely to blame...

[Zoarre]

it is likely that this group [netexplorer.org] was instrumental in obtaining official support for nvidia cards in freebsd. the page isn't updated often but there is a petition and some history of the effort.

i never considered petitions to corporations to be effective. i'm happy to be wrong.

Re:I like it

[rplacd]

You can avoid the chmod 666 if you run xdm. Simply edit /usr/X11R6/lib/X11/xdm/GiveConsole and add

chown $USER /dev/nvidia*

Make a similar change to TakeConsole (the examples in the file'll help).

I realize this isn't necessary for most people (most people don't have other users logging in), but it's still good practice.

Re:NetBSD

[be-fan]

The kernel portability layer is already open. The FreeBSD-nvidia project even got some initial results porting the Linux version. However, there are some issues in the binary part that held up the port. Given that they've most likely cleaned up the issues in the binary part for the FreeBSD port (why bother maintaining two different nearly identical binary modules?) a port to NetBSD should be fairly easy.

Re:Great! But...

[phoenix_rizzen]

There is no "emulation" in FreeBSD. FreeBSD supports Linux binaries. It is compatibility, not emulation. When an ELF binary is executed the loader looks to see what kind it is. If it's FreeBSD, then it load the FreeBSD kernel table (or ABI or whatever that thing is called). If it's a Linux binary, then it loads the Linux ABI. All that changes is the name of the system calls.

It works!

[Icy]

ICY> glxgears
7377 frames in 5.0 seconds = 1475.400 FPS
7359 frames in 5.0 seconds = 1471.800 FPS
7342 frames in 5.0 seconds = 1468.400 FPS
7316 frames in 5.0 seconds = 1463.200 FPS

ICY> uname -a
FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Wed Nov 6 09:29:55 EST 2002 root@:/usr/obj/usr/src/sys/ICY i386

libc required a little editing (that damn __sF), but it works.

Re:Great! But...

[Vinum]

It is a little more complex than that if you consider that linux binaries and freebsd (and every other freaking unix in the world) use a different method to access system calls. :)

Unix machines (like FreeBSD) push parameters to the system call to the stack then call int 80h. That is sometimes called the C convention. Linux on the other hands follows the Microsoft (or called Pascal sometimes) convention of putting parameters into registers then call int 80h.

It isn't a huge deal, since you should in theory always preserve registers before a system call anyway... but freebsd perserves all registers besides EAX anyway... so whatever. In theory the Unix convention is supposed to be faster but I haven't personally benchmarked it ever...

The kernel table isn't such a big deal, it is porting the actual systems calls from the libc where most of the work gets done. (Few applications actually call the kernel, they do it through the libs)