Slashdot Mirror
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."
You were saying?
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
Rumor has it that it works with -CURRENT after you disable a check in nv-freebsd.h.
Dinivin
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
just letting people know we've mirrored the freebsd drivers in australia at
d /
http://planetmirror.com/pub/nvidia/drivers/freebs
cheers,
-jason
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
--
Everyone who uses Yahoo! uses FreeBSD...
There's no "instead of" here, they have both.
OS X's userspace is from FreeBSD but the kernel is Mach, not FreeBSD.
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.
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.
Okay .. i dont know what HOWTO you have been reading but for redhat and Mandrake all you have to do is:
/usr/src/redhat/SPECS/NVIDIA*.spec
rpm -ivh NVIDIA*.src.rpm
and then
rpmbuild -bb
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
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/. BSD-heads who want in on a desktop project are encouraged to contribute ideas.
Knowledge is power. Knowledge shared is power multiplied.
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.
A deep unwavering belief is a sure sign you're missing something...
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)