Slashdot Mirror

← Back to Stories (view on slashdot.org)

LKM NVidia Drivers Now Available For NetBSD

Posted by timothy on from the pop-in-pop-out dept.

Dan writes "Quentin Garnier has made a loadable kernel module (LKM) version of the NVidia drivers on NetBSD. This release is very preliminary, rough and mostly meant to test the installation procedure. You will need a NetBSD-current system but the downloadable drivers code itself should be quite backward compatible with some caveats. For example, you need 'options KVM86' in your kernel config. His NVidia drivers on NetBSD page indicates that known working hardware includes RIVA TNT2 Model 64 (PCI), GeForce2 MX/MX 400, Vanta(AGP) and more!"

35 comments

  1. The answer is DRI! by motown · · Score: 5, Informative

    As I already pointed out in this post, it would be a lot easier for both NVIDIA and others if NVIDIA just based its driver model on DRI.

    --
    "Oooh, does that mean we get to kick some puffy white mad zionist butt?"
    1. Re:The answer is DRI! by ctr2sprt · · Score: 4, Interesting
      Probably so, but back when NVIDIA first released their drivers it really was reasonable to stay away from DRI, do their own implementation of AGP, etc. Now I suspect a lot of it is inertia: if they wanted to rewrite their drivers to use DRI, they'd probably have to start nearly from scratch. This would take a long time, and the end result would likely be worse than what we have now (at first, anyway), so nobody would use it.

      I'm not saying you're wrong. I think this is the direction NVIDIA needs to take in the future, and I expect they will take it (eventually). But it's not something that can be done in even a couple weeks.

      (Actually, I am kind of hoping that this is the reason behind the delay in FreeBSD drivers: the *BSD and Linux teams are trying to work on a much more portable driver, which might well mean DRI. Of course, there are lots of other things to worry about in the FreeBSD drivers since nearly all OpenGL games are going to be run in the Linux emulator, so maybe it's not that simple after all.)

    2. Re:The answer is DRI! by Anonymous Coward · · Score: 0

      The reason not to use DRI was a different one. The current nvidia driver architecture shares 90% of the code between *nix and Windows. The other 10% is system dependant (x11/gdi ...). If nvidia used dri they couldn't share the code between all platforms.

    3. Re:The answer is DRI! by Anonymous Coward · · Score: 0

      I'm one of those interested. Seriously.

    4. Re:The answer is DRI! by X-Guy · · Score: 1

      Why? Does the DRI support multiple screens yet? Multiple simultaneous cards? Does it support accelerated indirect rendering yet? What about workstation features like overlays or window IDs? Quad-buffered stereo? NVIDIA's drivers do all these things and the DRI still sucks like it did three years ago. NVIDIA was wise to stay away from it.

  2. FACT: Jesus uses OpenBSD (nt) by Anonymous Coward · · Score: 0

    Yes, i know, i used the nt think from k5. Sorry.

  3. Re:Fact by Anonymous Coward · · Score: 0, Funny

    BSD is alive! Have you accepted BSD as your personal OS?

  4. What about OpenBSD by motown · · Score: 5, Interesting

    I checked this guy's site, and it appears he really did some impressive work hacking around those binary FreeBSD drivers and somehow getting them to work with NetBSD (even though there are currently some serious issues left, but it looks like he already completed the hard part of the work).

    With this feat, I wonder if a similar hack could now also be made for OpenBSD... Although probably nobody would be interested in this. I mean, come on: why modify an otherwise stable and highly secure (mostly server) OS through the use of experimental patches, combined with binary code originally meant for another OS, which would only be beneficial to 3d graphics support? ;) But still I'm wondering, purely from a theoretical and technical point of view, how much more difficult it would be. Not much, I reckon, since the BSD's (especially NetBSD and OpenBSD) are very closely related and therefore share a lot of code and architecture.

    I guess that the next (sufficiently interesting) step would be Darwin (the x86-port ofcourse). Since Darwin is more distantly related from the BSD family than the rest of the BSD's (it's based on a FreeBSD-like layer on top of a microkernel), this might prove to be more of a challenge. :)

    Aaaargh! So many operating systems to potentially support! Do you see now why I am such a proponent of DRI? ;)

    --
    "Oooh, does that mean we get to kick some puffy white mad zionist butt?"
    1. Re:What about OpenBSD by mirabilos · · Score: 1

      I'd like that too, and maybe I'll try it out the
      next days.
      I've got a friend who's only prevented from using
      OpenBSD (or MirBSD) as his main OS because there
      {we,a}re no nVidia "drivers" (though I dislike to
      speak of "drivers" in a unix OS).

      --
      My Karma isn't excellent, damn it! (And /. still does not get UTF-8 right in 2012. Wow.)
    2. Re:What about OpenBSD by Anonymous Coward · · Score: 0

      Disclaimer : I'm not a kernel developper, and I'm not an OpenBSD user.

      How many hardware opengl board are supported under OpenBSD at the moment ? Answer that question and you'll know if such a port is usefull/less...
      Well, the thing is, if OpenBSD isn't yet much geared toward OpenGL stuff, the first real hardware driver would have to deal with eventual kernel inefficencies in that area, which could potentially slow down the driver development. In the case of Nvidia, if you add up the fact that it's not a driver made from the ground up for OpenBSD, then it's several minefields stacked up you're dealing with. So it might not be the best way of starting OpenGL hardware support.

      About Darwin, I remember reading a while ago that the main difficulty in the FreeBSD port was about some driver function requiring access to a certain memory part (to avoid memcopies) that the kernel wouldn't allow. That zero copy trick might be trickier in Darwin, as most service parts (like drivers) of the kernel are moved out of the core, implying lots of messaging and memory transferts between the core and the external services.
      But I'm no kernel developer, so I'm just guessing.

  5. Unloadable kernel modules are obsolete now? by Rares+Marian · · Score: 1

    Sorry I'm in redundancy nazi mode now. Redundancy is most common cause of pointless acronyms.

    --
    The message on the other side of this sig is false.
    1. Re:Unloadable kernel modules are obsolete now? by Anonymous Coward · · Score: 0

      Yeah. Also strange how you don't understand the difference between acronym and abbreviation, isn't it?

      Hint: "LKM" is not the former, unless you say "luh-kum" or something.

      Shot down, eh?

    2. Re:Unloadable kernel modules are obsolete now? by Rares+Marian · · Score: 1

      I call as I see em.

      --
      The message on the other side of this sig is false.
    3. Re:Unloadable kernel modules are obsolete now? by Anonymous Coward · · Score: 0

      On the contrary - an abbreviation is simply a shortening of a word, e.g abbr. for abbreviation. An acronym is a word formed from (usually) the first letters of each word of a longer phrase.

      LKM is most definitely an acronym.

  6. re: I dislike to speak of "drivers" in a unix OS?! by Anonymous Coward · · Score: 0

    Ummm they're hardware drivers whehter or not you're in Linux, *BSD, Windows, Mac OS, Solaris, QNX, etc...

    How does your dislike for the term "drivers" for *nix OSes affect what it actually is? I'm curious... (Though not curious enough to login -- because I believe the answer will reek of "crackpot".)

  7. Re: I dislike to speak of "drivers" in a unix OS?! by Anonymous Coward · · Score: 0

    Not really. Just, I consider "drivers" to be .sys files ;)
    I don't know how to call the unix kernel code
    that's possibly a driver, but the term "drivers"
    is bad in context, such as install a driver

    since it's in the kernel or not

  8. Just publish the spec by Animats · · Score: 1
    It's really annoying that NVidia keeps their board spec a secret. QNX doesn't support NVidia for that reason.

    NVidia does this partly to protect their overpriced "pro" Quadro line, which is basically the same as the GEForce line but costs about 3x as much. GeForce boards are crippled in software to keep them from doing a few things the Quadro boards do. Given the dinky market for "pro" graphics boards, I'm surprised they still bother.

  9. Re:*BSD is dying by Anonymous Coward · · Score: 0

    You must be a very stupid kid. Kind of a "geek".

  10. No, the answer is DRM by Anonymous Coward · · Score: 0

    and MICR0S0FT is the QUESTI0N, M0THERFUCKER