Slashdot Mirror
New FreeBSD NVIDIA Drivers Available
CoolVibe writes "Finally, the officieal Nvidia drivers for FreeBSD have been updated to version 4365. The drivers are available at Nvidia's website. They are not in the ports yet, but that won't take very long. Also, this driver supports both STABLE and CURRENT officially. I am using them at the moment, and boy, these fix many problems I had with the older ones."
Wish I could be more excited but I dumped my NVidia card a month or so ago.
I am glad to see this though, the old NVidia FreeBSD drivers were pretty horrid.
To ATi I would say:
"Where are my finished Linux drivers, and FreeBSD drivers ATi? ARE YOU LISTENING?"
Seriously. Their Win32 drivers are pretty decent, but their Linux drivers need some serious performance and OpenGL work done.
In their infinite wisdom, they do not provide FreeBSD drivers, nor the information to commercial companies that want to write drivers for their 9600/9700/9800 series of cards.
It's sad really. This almost makes me wish I had kept my NVidia card...
How does 'never had anythingto do with the GPL' make them suck? They're releasing drivers for a GPL and BSD-licensed OS, that's not good enough for you?
Sorry, I guess you're one of those people who will never be happy until no one anywhere can make any money off of any software or anything related to software. Nevermind.
This is good news.
:)
About every second time I reboot my computer the xdm login screen is all messed up. I have to hit ctlr-alt-backspace to reinit x, so that the drivers kick in properly. If I don't it locks up the computer during the login sequence. It is the same for both my 4.8 and 5.0 machine.
I am currently downloading the new drivers
Saying your OS is the best because more people use it is like saying MacDonalds make the best food
Wow. This driver is MUCH better than the old one. Five minutes without a crash! :)
The lack of stable Nvidia drivers have been the major roadblock preventing me from switching to FreeBSD full-time.
The only thing that would make this better is if it was an open source driver, but this is good enough for now...
I had so many problems with the old drivers on my -STABLE box. Couldn't run more than one GL app per X session or my whole system would lock up and had to be rebooted. Lots of instability, crashes, and broken apps. Hope this fixes things.
Hopefully fixes the issues where if I start Galeon X crashes out. Least there is now official support for 5.x so that I won't have to patch the kernel again
Rus
Cheap UK and US VPS
Since you obviously don't like the closed-source driver, you should use xfree's "nv" driver -- You should do that anyhow, they are SOOOO great.
Anyone know what Apple uses for video drivers in Mac OS X when you plop in a NVIDIA-based video card?
This is much better. The first one recommended that I recompile the kernel, and X with no optimizations, but I tried it anyway and it didn't work as expected, but this one seems to work okay (a few bugs, but no show stoppers) even with these optimizations in make.conf on -stable:
The install was pretty painless, too.
# make clean sig
When you use X on your local host, it doesn't really use the network stack. Read up on pipes and domain sockets before you spout off like that. You can still use X without having network support in your kernel. You only need sockets Ergo, nothing moves across any network. So all your points are basically uninformed drivel.
Domain sockets (like the ones X uses locally) are a very efficient way to do IPC. Every write() on a domain socket in in practice a memcpy/memmove operation. So the overhead is really really small. And you get network transparancy basically for free. It has _no_ impact whatsoever on what you do locally.
If you want to point the blame at the "slowness" of X, blame the toolkits. GTK is slow. Motif is slow. Qt is slow. Xlib is VERY fast, but cumbersome to use.
All I can say in regards to the nvidia drivers is that they are excellent. I followed their directions to the T and in less than thirty minutes had great results. Seeing Quake 3 run on FreeBSD is truly a beautiful thing.
Note: That is with their very first release of the FreeBSD driver. I am sure it is even better now.
./revolution
Even if you hate the idea of network transparency and all that, the rendering code could be reused, especially since the license allows that to happen. Other projects out there don't offer the level of support for the various chipsets that XFree86 does. So it isn't a total waste, is it?
Just a personal experience. I grabbed this about 2 days ago and my -STABLE system crashed several times when I used the FreeBSD agp kernel module. I've changed over to use the builtin AGP support and everything has been rock-solid.
Except the Linux compatibility layer will be illegal thanks to SCO :(
Well it would be if there were any real Linux kernel source code in the layer, but there is not. It's mostly a simple translation between Linux system calls and BSD system calls. Thats why the Linux compat module is NOT GPL'ed...
BWP
cvsup, portupgrade and it is working like charm.
How can BSD be dying when it has a mascot [freebsd.org] like this?! Linux needs to get its act together if it's going to compete with the kind of hot chicks and gorgeous babes that BSD has to offer!
You just can't take Linux seriously when its fronted by losers like these. You Linux groupies need to find some sexy girls like her! I mean just look at this girl ! Doesn't she [madchat.org] make you hard? I know this little hottie floats my boat! This guy looks like he is about to cream his pants standing next to such a fox . As you can see, no man can resist this sexy little cock teaser . Even this old bearded Unix guru is apparently unable to take his eyes off her !
With sexy chicks [spilth.org] like the lovely Ceren you will have people queuing up to buy open source products. Look! This guy can't get in there fast enough with her [kurtspace.com] in the doorway! Come on, you must admit she [kurtspace.com] is better than an overweight penguin! Don't you wish you could get one of these [drexel.edu]? Join the campaign for more cute [madchat.org] open source babes [madchat.org] today!
Funny. The old NVIDIA driver was ok for me- stable with 4.7, MSI GeForce Ti4200 128MB. No probs, no artifacts.
But with 4.8-RELEASE when I recently tried adding IPFILTER it locks up on the KDM login screen. And also when I do startx. I confirmed that it's with IPFILTER (with the default accept). I doubt it's a firewall rule issue, coz when I flush the IPFW rules (default DENY) in a kernel without IPFILTER, things still work fine.
Not sure why having ipfilter would do that.
No, the grandparent is right. X sucks. It was useful when computers were expensive. This is no longer the case. Now it is just crippling things.
I really, really wish graphics code was in the kernel. Sending everything through a pipe is not as efficient as you suggest. The pipe itself may be fast, but everything needs to be encoded and decoded.
Consider an example like "draw a line."
Currently, the client must call a function in the X client library, which then encodes this into a message and uses a select loop to write the message to a pipe. This is not one, but many syscalls. The kernel must allocate buffer space to handle this specific pipe. Then, the server receives this command from its select loop, decodes it, and executes it.
In my model, the client executes a syscall with a pointer to the data. The kernel then executes the draw operation, possibly inside the interrupt handler. This is easily a hundred times faster than the above model, uses less memory, does far less needless work, and is far more simple and elegant, with the only drawback being a lack of network transparency -- which could easily be added with a userland client and server.
The performance increase is even greater for a command like "draw a bitmap."
Currently, the bitmap is being fragmented and sent through multiple syscalls which then makes four copies of it: from client into send buffer, from send buffer into receive buffer, from receive buffer into server, and from server into video memory.
Chances are, the server has an extra buffer because it cannot handle the data until it is complete. So that's another copy.
With the graphics in the kernel, the bitmap is copied ONCE: from the client directly into video memory, from the single syscall.
"[A] high IQ is like a Jeep; you will still get stuck, just farther from help!" --Just d' FAQs, c.g.a
X has direct access to the graphics hardware. So blitting a bitmap on to a screen is really no more labour intensive than doing it from the kernel. You want to draw a line? Fine, you do it. You want to blit a bitmap on the screen, sure, you can either do it through DRI, or just through DGA. Either one is fine. Oh, and if you really need to you can use the raw X lib.
The only point as to were you are right is with ancient framebuffers. Hello, welcome to the 21st century. We have accelerated drivers for X that do basically the same as writing direct to the video memory. Your point is so moot it isn't funny.
A display server in the kernel has no place in the kernel. Yeah it's IPC, but windows uses IPC to draw windows, OS X uses IPC to draw windows, OS/2 uses IPC to draw windows, and the list goes on and on. Using domain sockets is as efficient as it gets.
The library calls cause no more overhead as calling into say, libc. And I never said a pipe. I said domain socket. You don't need to marshall your data to send it through. That's nonsense.
X gives us a nice graphics solution that gives us network transparancy for free, and also with the added benefit that it can all run from userspace.
X is great. You are full of it.