Follow Slashdot stories on Twitter


Forgot your password?
Graphics Software Hardware

nForce2 GART Driver Finally Released For Linux 238

Rejoice, Radeon owners! For those of you who bought an nForce2 motherboard with the hopes of doing a bit of linux gaming on it, I'm sure it was a pretty hard let down to find out there was no AGPGART driver for the nForce2 -- until now. nVidia has finally released a kernel patch for the 2.4.20 release that is now providing GART support. Perhaps this means that nVidia is re-thinking their closed source-isms in favor of a more open policy in the future. A note on AGP 3.0: Note that AGP 8x mode is not available in 2.4.xx series kernels. If you find that X will not start, try disabling 8X mode in your BIOS. AGP3.0 has been implemented in the 2.5 series.
This discussion has been archived. No new comments can be posted.

nForce2 GART Driver Finally Released For Linux

Comments Filter:
  • Closed-Source (Score:5, Interesting)

    by jobeus ( 639434 ) <jobe-slash@j[ ] ['obe' in gap]> on Sunday June 22, 2003 @03:57AM (#6265877) Homepage
    I believe nVidia's 'closed source'ism is due to the fact that their drivers for their video cards include code that is not theirs, and licensed from other companies, and thus not publishable... Thus, I can't really see this as a shift to a more open source view.
  • gaming already (Score:2, Interesting)

    by nick58b ( 536112 ) on Sunday June 22, 2003 @03:58AM (#6265884) Homepage
    I spent all last week playing Enemy Territory on Gentoo Linux with my NForce2 motherboard. I get similar framerates to the Windows version of the same game. Why exactly is this patch special?
  • by Bram Stolk ( 24781 ) on Sunday June 22, 2003 @04:00AM (#6265888) Homepage
    I wonder. Would this kernel patch be any
    help to the xbox-linux development to get
    a better understanding of the nForce2 chip?
    Maybe xbox-linux will have accelerated 3d in
    the future?
  • not quite there yet (Score:-1, Interesting)

    by Imperator ( 17614 ) <(ten.reknehsremo) (ta) (2todhsals)> on Sunday June 22, 2003 @04:03AM (#6265896)
    I'm not buying any more nVidia cards until they release their drivers as open source, or alternatively reveal the specifications necessary for the community to write open source drivers. I am not willing to mess with binary kernel modules, since that means using a stock distro kernel and having no assurance that future kernels will have the module compiled for them.
  • Re:Radeon owners? (Score:3, Interesting)

    by Kourino ( 206616 ) on Sunday June 22, 2003 @04:43AM (#6265998) Homepage
    It's not really a Slashdot nono. You don't get any help from kernel developers, period, if you experience problems on a system where any closed-source drivers have ever been loaded during the current power cycle. And for good reason; you can't really analyze the code to see if it's, say, smashing stack, or scribbling on the page cache, if you don't have the source. Since you can't rule out the closed-source elements because of this, it's harder to properly isolate the cause of, say, an oops; also, people like Alan have better things to do than narrow the cause of an oops down to code they can't debug.
  • by Anonymous Coward on Sunday June 22, 2003 @04:51AM (#6266013)
    Yeah but open source drivers tend to sux. Maybe I'm being unfair but a bunch of free software hippes can not hope to compete with a professionally made driver set, Your talking about full on assembly voodoo to get every last possible frame out of the hareware, While, in general, the OSS community (whatever way yon take it) has done some mind blowing work over the years but I think that this is just out of their reach.

    Case in point - drivers for the Radeon series have been in the kernel tree (DRI rendering) for years and yet no one has done anything with them, ATI now provide their own set for linux in the same way as NVIDIA.

    Further when 3dfx were still around the specifications where avilable and yet the community failed to show any interest in creating their own.

    I think that open source is great and all but it is not some magic cure-all for world hunger. Propriety software does have a place and I just think this is one of them,

    BTW,,, I don't think your need to have a stock kernel just to use the driver, I compiled and was able to run the module on my machine with out too much drama. All you have to do is make sure you have module support, in the place.

  • by Anonymous Coward on Sunday June 22, 2003 @05:04AM (#6266037)
    If you were going to use the software only internally, and not make any money selling it, why would it be a problem to release it for free to all your competitors?
  • by evilviper ( 135110 ) on Sunday June 22, 2003 @06:45AM (#6266228) Journal
    or alternatively reveal the specifications necessary for the community to write open source drivers.

    Yeah, because that worked so well for ATI??? You can't get TV-out to work on any ATI cards, and TV-in is just barely functional, even after hours upon hours of getting the software to compile... 4 entirely different Linux distros, 3 different versions of avview, and 2 posts to the Gatos mailing list, and I have never been able to capture audio. That doesn't even mention that avview is a very weak piece of software, with a lot of limitations (1GB filesize max? That sucks), and it is essentially the only program that will work with ATI cards (theoretically, I actually never got it to work right).

    Personally, I would go for the open source software rather than the closed source, however, no software is useful to me if it doesn't work, and that has been my experience with ATI. As for your die-hard aversion to binary drivers, I have to wonder why. In the world of Windows and Apples, ALL drivers are closed source... There is a reason for that; people would rather have a house than the blueprints for making a house.

    The FreeBSD version of the NVidia drivers seems to be 90% source, and 10% binary, so it's likely you would be able to patch that if you ever needed to do so. In that way, it's not really any worse of a license than with D.J.B.'s software.

    Sorry, but I don't follow your hard-line, and I don't really believe you do either... I bought my NVidia videocards knowing that they will work on Linux and FreeBSD, not so that they MIGHT work a few years in the future. They work right now, and nothing will stop them from working with the same software in the future. I'm not screwed if the Open Source driver developer decides not to fix a bug; so I'd much rather have a company that supports their hardware on my OS, rather than barely-working, open source drivers.
  • by motown ( 178312 ) on Sunday June 22, 2003 @10:00AM (#6266733)
    Alright, NVIDIA's 3d-drivers are closed-source. But they do offer kick-ass performance under Linux.

    Unfortunately, they have been jumping through all sorts of hoops in order to keep releasing closed source 3d driver binaries, while keeping them up to date with XFree86 and Linux kernel updates. This is unnecessary, since XFree86 already has an infrastructure in place, which is well suited to solve this problem: The Direct Rendering Infrastructure, or DRI.

    In the past, NVIDIA's argument against DRI could have been that DRI wasn't a sufficiently mature technology, but nowadays, this is no longer an issue. Also, NVIDIA is the only company in the graphic card business, which used a different proprietary infrastructure for their 3d drivers. All the other companies, such as ATI, Matrox and Videologic (regardless if they release sources to their 3d-code or not) all use the DRI-model.

    Currently, there DRI-model fits NVIDIA's predicament perfectly: NVIDIA has already released the sources to the 2d-part of their drivers long ago (and they have been part of XFree86 for quite some time), but they just want to keep the 3d-aspect closed source. That's exactly how DRI-based drivers work! A 2D-part, which is part of XFree86, combined with a 3d-part, which plugs into the 2D-part of the driver through a (standardized) modular architecture!

    An added advantage is that these binary DRI modules are OS-independent, just architecture-dependent. It is even possible to use DRI modules with GUI systems other than XFree86. DirectFB has been (successfully) working on DRI-support.

    In other words: had NVIDIA already switched to the DRI model for their driver, then they wouldn't have had to go through the trouble of porting their drivers to FreeBSD. The same binary module already available for Linux would have worked on a FreeBSD system with a DRI-enabled kernel (which FreeBSD already supports). The DRI modular architecture has been deliberately designed that way. All NVIDIA would have to do is release the 2D specs under open source (which they already have done) and compile DRI module releases once for each architecture they'd want to support: x86, Motorola/IBM G4, IA64 and AMD64 architectures. These modules would then work out of the box on any OS with DRI support (on any of these architectures).

    Example: if Zeta, the BeOS "reincarnation", would be updated to work with DRI modules, then it would be able to make use of the 3d capabilities on NVIDIA-cards right away!

    Furthermore, the DRI model would have made it a necessity vor NVIDIA to release open source AGPGART kernel code for the NForce2 in the first place, because this would be required for even NVIDIA's drivers to work. A proprietary alternative AGP handling hack (like what they have been using in their drivers until now) would have made no sense.

    Lastly, the fact that NVIDIA would then not be using a different architecture then the other companies would be causing a lot less headaches for 3d application developers under Linux. Right now, many games and other applications under Linux, such as Winex 3.0 and the Neverwinter Nights port, have been optimised to work with NVIDIA's drivers, but still need work on proper support for DRI (basically covering all other 3d solutions for Linux).

    If any NVIDIA driver engineer is currently reading this: please seriously consider switching your drivers to the DRI model! It would save both you and others a lot of work and potential compatibility problems, without having to release any 3d driver sources. This way, you would also instantly be expanding the number of operating systems able to support 3d on NVIDIA cards, without you having to do any additional work for it!

    The only disadvantage for NVIDIA that I can think of is the status quo that NVIDIA would possibly like to uphold: games and other 3d applications having better support for NVIDIA (currently being the market leader on Linux) and all the DRI-using competitors remaining behind. In the longer term, how
  • by CondeZer0 ( 158969 ) on Sunday June 22, 2003 @11:03AM (#6267077) Homepage
    heh, lets try again ;-)

    First, before downloading anything you need to read and accept this license:

    2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux operating system may be copied and redistributed,
    provided that the binary files thereof are not modified in any way (except for unzipping of compressed files).

    2.1.3 Limitations.

    No Reverse Engineering. Customer may not reverse engineer, decompile, or disassemble the SOFTWARE, nor attempt in any other manner to obtain the source code.

    No Separation of Components. The SOFTWARE is licensed as a single product. Its component parts may not be separated for use on more than one computer, nor otherwise used separately from the other parts.

    No Rental. Customer may not rent or lease the SOFTWARE to someone else.

    [bold mine]

    And so on... I'm no lawyer, but this doesn't look too good to me, let's look at the actual files...

    $ ls
    GNULicense.txt Makefile NVLicense.txt README ReleaseNotes.pdf nvaudio nvnet

    $ ls nvnet/
    Makefile adapter.h basetype.h nvnet.c nvnet.h nvnetlib.o os.h phy.h

    $ cat nvnet/nvnet.c | grep '^|\*'
    |* (c) NVIDIA Corporation. All rights reserved


    I don't know about you, but this doesn't look too GPL-compatible, and I'm not going to look into that code.

    $ file nvnet/nvnetlib.o
    nvnet/nvnetlib.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

    lol, they even forgot to strip it!!
    Still, if you remember the license, you are not allowed to do anything that might give you the src code. So I'm sure you could get some good info from that, but I seriously doubt of how you could use that info legally for anything...

    Now for the audio:

    $ ls nvaudio/
    Makefile i810_audio-nforce23.patch

    $ cat nvaudio/i810_audio-nforce23.patch |grep '^[+-][^+-]'
    +#define PCI_DEVICE_ID_NVIDIA_MCP2_AUDIO 0x006a
    +#define PCI_DEVICE_ID_NVIDIA_MCP3_AUDIO 0x00da

    As you can see, the 'driver' for nvaudio is a 10 line patch(to the kernel code, and should be under the GPL) that does little more than adding the necessary ids to detect the chip as a Intel i810 clone, which is what I meant by 'dumbed down' as the audio chip in the NForce2 has *many* features not in i810.

    In resume:

    - nvnet: Nvidia provides a binary(un-striped!)+src(wrapper?) driver under a draconian license that makes it quite useless for those that want to stay legal, I haven't looked at the provided code(maybe some day I will want to write a Plan9 driver, and I don't want to be 'tainted'), but I bet it's little more than a wrapper for the binary file, that is basically what they do with the video drivers, and it's just so it kind of works across different kernel versions. And what matters most, if you want to write a driver for *BSD or any other OSs you are out of luck.

    - nvaudio: as I said in my previous post, very basic support is provided but nothing near full support exists, from either OSS or binary/propietary drivers.

    Happy now? Best wishes


Never buy from a rich salesman. -- Goldenstern