Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Graphics Software Hardware

nForce2 GART Driver Finally Released For Linux 238

Posted by timothy from the expanding-choices dept.
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 More

nForce2 GART Driver Finally Released For Linux

Comments Filter:

  • Closed-Source (Score:5, Interesting)

    by jobeus ( 639434 ) <jobe-slash@jobeu[ ]et ['s.n' 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.
    • This has been discussed before on the nvnews.net forums, and essentially Nvidia could open up their driver, or at the very least parts of it...

      Consider that the nforce (not the graphics) driver only uses stereo sound b/c the dolby code is properiety and cannot be released. Instead, Nvidia could keep that part closed (binary only d/l) but open the other parts... This is true with their graphics drivers as well... they *could* open up the parts that do not contain the IP of other co's...

      So far the best rea
      • Why can't they obfuscate their source code ? At least then it wouldn't be binary-only but really difficult for humans to figure out. Kind of a happy medium.
        • And would be a violation of ANY OSS license.

    • Re:Closed-Source (Score:2, Insightful)

      by Anonymous Coward
      I think that there is also a problem with politics, In that the drivers are seen as an asset by the investors, That ATI took years to get theirs right, serves to reinforce this view. Ie people with MBA's have no idea when it comes to engineering. Even if the board and the engineering team think that open source is a good idea then they will still not release them for fear of being sued by the corporate members - somthing that happens in public company's all the time. The sucky thing is that engineers tend t

    • 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...

      If that was the reason then they could at least releast the specs for their chipset (the hardware interface, not the hardware's sourcecode).

      I recently bought a MSI K7N2G-L motherboard, and saying that I was disappointed with nVidia when I discovered that the nForce2 chipset wasn't properly supported for Linux,

    • Re:Closed-Source (Score:5, Informative)

      by Simon Kongshoj ( 581494 ) <skongshoj@oncabl ... inus threevowels> on Sunday June 22, 2003 @06:34AM (#6266210) Homepage

      They could handle this like Matrox did with their G-series of cards on Linux. Matrox put all the stuff that they couldn't legally free in a library (mga_HALlib.so), which the driver (which is free software itself) can call. Interestingly, the driver can run without the HALlib being present, but the graphics card loses some of its features in that case.

      That seems to me like the way to go for companies who want to embrace free software, but aren't legally allowed to release all their code.

      • Of course, releasing most of their code and then reducing all the stuff they can't publish into a library makes it that much easier to reverse engineer the remaining closed source code. After all, the open source stuff has to make calls to that library, so it should be more obvious what those calls do, at least more so than with a completely closed source driver. I guess it depends on how clear the open source code is.

        That being said, the Matrox G-series cards aren't anything to write home to mother abou

        • Matrox' open-source driver is apparently based on what XFree86 coders had already done. It is written in approximately the same style as what you see in the rest of those X drivers, so it's reasonably readable. They apparently haven't been needlessly obfuscating things, which is cool. It would be nice if other vendors adopted the model of isolating the non-free stuff in an optional library and using an open-source driver with that. If they can, that is; if crucial code in the main driver is non-free it may

        • who cares if it is reversed engineered? No skin off NVIDIA's back. If they keep their licensed IP closed source, and someone reverse engineers it, that isn't NVIDIA's fault.

          Unless of course, the license terms disallow opensource derravitives from the licensed work.

          But I can't believe the /. crowd believes this load of BS. The drivers are closed source because most of the 3D logic and techniques are contained in SOFTWARE, not hardware, in the form of a driver that runs on NVIDIA's "3D" chip. How else do yo

    • This doesn't at all explain why on earth all of their nForce2 drivers are closed source. I don't care what argument they can come up with, they don't need to close source the ethernet and audio drivers for that chipset. It's ridiculous.

      I consider any closed source code to be untrustworthy and suspicious. Too much of it sends infrmation back to the company that made it, which is a security breach. Also inadvertant bugs that I can't do anything about may also compromise the security of my system.

      Running

      • A FOSS ethernet driver would be bundled by Mandrake, thus enabling me to go on line OOTB through my ethernet-interfaced DSL modem to collect the proprietary video driver if I wanted accelerated 3D. Sound is (hawk, spit) Intel i810 (I'd be even more pleased if the next nForce was based on the Yamaha chips instead), and non-3D video is fine with the FOSS X driver.

    • Less of a problem if nvidia released DRI modules (Score:5, Interesting)

      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
    • 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...

      That is the usual line of bullshit that I doubt even comes from NVidia, it comes from people like you. If there is in fact code they have to which they do not own the copyright or appropriate license (which I doubt, personally) then they can place that code, and only that code, in a binary module.
    • I mean they also cheat or "optimize" using drvers for certain benchmarks and games that in many cases reduce the image quality of the games (why i call it cheating) without informing the consumer or developers. I'm not singleing out nvidia here as i'm sure others do it too (ATI was also caught doing a minor cheat this year and some major ones a few years ago).

      Wouldn't this be a major reason to hide/close your source.
  • I think it's amazing how hardware vendors continuously become more engaged in writing linux drivers. When I think back a couple of years, I could not buy the graphics card I wanted because I was not sure if it would ever be supported...
  • And people used to smite me for all those times I've been playing TuxRacer [tuxracer.com] on WinXP.

    Thank you Nvidia. Other than a having a girlfriend, you have given me most of my dignity back.

  • gaming already (Score:2, Interesting)

    by nick58b ( 536112 )
    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?

    • Re:gaming already (Score:5, Informative)

      by Anonymous Coward on Sunday June 22, 2003 @04:31AM (#6265977)
      Because they was no way to use the AGP port without using the binary Nvidia drivers.. which was ok if you happened to have a nvidia graphics card in your nforce motherboard, but if you were running a ATI, or matrox card you couldn't load the AGP driver :-(
      It was one of the reasons I purchased a ti4200 to drop in my nforce1(415-D - no inbuilt graphics card) (and now nforce2) motherboard.

      I assume you were using the IGP.. as this would have allowed the nvidia drivers to load.

  • Useful for xbox-linux? (Score:3, Interesting)

    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?
    • I thought the X-Box was based on the Nforce 1, not Nforce 2 Northbridge...

      But probably not... in order to get 3d on Xbox Linux you would need to hack one of the Nvidia graphics drivers for Linux, and since they are still closed source that would be difficult.

      _CMK
    • Nforce1 & 2 in the PC arena are made for AMD CPU's. The XBox using an Intel P3 with an integrated Geforce3 Core. So this would be probably zero help for xbox-linux.

  • GART is relevant to the M/B chipset too (Score:5, Informative)

    by Rolman ( 120909 ) on Sunday June 22, 2003 @04:04AM (#6265900)
    Radeon owners? Well, that sounds a little bit misleading and should be differently worded, but certainly the nforce2 chipset has features that are not video specific and can be attractive to Radeon users.

    The nforce2 uses a 128 bit memory architecture that benefits the system's memory bandwidth as a whole. The GART helps here because you can now combine this architecture with a separate AGP video card, neglecting the relatively lower-end video core inside the nforce2.

    GART is an AGP bridge feature, not a Video Chip feature, and the nforce2 is the best AMD compatible chipset out there, combine that with the current best Video chipset out there, which right now happens to be a Radeon, and there you have it, Radeon owners like myself rejoicing :)

  • Some info (Score:5, Informative)

    by localghost ( 659616 ) <dleblanc@gmail.com> on Sunday June 22, 2003 @04:18AM (#6265945)
    I have an nForce board and have been waiting for this for a while. I don't like having to use nVidia's built-in AGP support. However, many people with an nForce board have probably been using this patch for a while. It's been in the -ac patch in the kernel for a few weeks now, and the patch has been floating around a little longer than that. You can most likely expect it to be in kernel 2.4.22.

    Second, some people seem to misunderstand the significance of this. nVidia's driver has built-in AGP support already, you don't need GART for AGP to work. This is only true, though, if you own a card that is made by nVidia. Radeon owners prior to now had to use the PCI bus for graphics if they had an nForce or nForce2 chipset.

  • XFree86 4.3 & Radeon 9200/9500/9700 HOWTO (Score:4, Informative)

    by Plug ( 14127 ) on Sunday June 22, 2003 @04:26AM (#6265968) Homepage
    More useful (no kernel recompilation required) is that a gentleman named Robbie Ward has applied NVidia's AGPGART patch to the Radeon kernel module builder, and the result can be found at here [robbieward.co.uk].

    You can find a small HOWTO on getting the lot going at the Waikato Linux Users' Group wiki, at http://www.wlug.org.nz/RadeonOnNforce [wlug.org.nz]. Have a look around while you're there, its an excellent source of information and we'd really love you to add to it.
    • Has anyone had luck getting 8500-series working in X 4.3?

  • Some tips and hints; (Score:5, Informative)

    by jericho4.0 ( 565125 ) on Sunday June 22, 2003 @05:13AM (#6266063)
    As someone who has been struggling with this issue for a while now, maybe others will find this helpfull. I have a Radeon9700 Pro, and a A7N8X mobo. Other combos might or might not have the same probs, although it seems that many similar combos do.

    First you need to compile it against 2.4.20. The agpgart patch (as written) will not patch 2.4.21. If you manually apply it, the compile will fail. If you remove the line 'agp_bridge.num_of_masks = 1' from the diff, it will compile, but DRI still wouldn't work for me.

    Unpack 2.4.20, apply the agpgart patch, compile, boot. Now 'make clean' in each individual directory in the nforce driver dir, make clean at top level leaves object files lying around. Then make,install. All should be good. ~6000fps in glxgears.

    Don't bother applying the ac patches against 2.4.20 to get native nforce IDE support, this will break the DRI. Instead put 'hdparm -c1 -d1 -u1 /dev/hda' in your startup somewhere. The end result is the same.

    I'm finally happy on the bleeding edge. I didn't have to set 4x AGP, but others have to.

  • ATI's driver includes its own tweaked version of agpgart which fully supports AGP 3.0 and 8x - I've patched it myself and it works beautifully. I assume Robbie Ward's driver does the same. I'm getting around 7000 FPS in glxgears and around 1100 in fgl_glxgears. The advantage of patching ATI's driver is that you don't have to patch and recompile the kernel each time you make a change to it

  • Still proprietary... (Score:3, Informative)

    by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Sunday June 22, 2003 @05:38AM (#6266111)
    Read the license. No way that code ever gets into the kernel:

    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).

    • i too was a bit worried about this. but upon downloading the code (just to see), i found this

      GNULicense.txt

      sitting in the top level :-D. they even refer to "your GNU/Linux distribution" instead of just plain 'ol "Linux". after reading a few other posts on the subject about this helping out radeon support (me buys radeon), i am a very happy camper! this will certainly make it into linux.

  • Other nForce linux drivers and docs (Score:3, Informative)

    by CondeZer0 ( 158969 ) on Sunday June 22, 2003 @06:01AM (#6266153) Homepage
    Now if only they could release the source for the nvnet Ethernet drivers [petitiononline.com]...

    Or at least release enough docs so that open source drivers could be implemented; I'm running 2.5.x, and had to use an additional network card because the (crappy)binary drivers from nvidia only support ancient kernels, not to mention there is no support for *BSD or other OSes.

    Better audio support would be nice too... ALSA handles it, but in a very dumbed down mode, with many features not supported because nvidia doesn't want to release the docs, and AFAIK there is not even binary drivers for that...

    But the network drivers are the biggest pain, in my company we have >20 Linux desktops, and is a PIA to have to install manually the drivers in each box, and pray that the kernel you are using is supported.

    Keep in mind that even if the nvidia binary graphics drivers are quite good, the nforce drivers are _crap_ and haven't been updated since November last year, there are various bugs that nvidia said would be fixed in the next release, but so far the users are stuck.

    Oh, well, I guess that I(and my company) will buy VIA based boards from now on... *sigh*

    Best wishes

    \\Uriel

    P.S.: Don't forget to sign the petition, maybe nvidia gets a clue when they realize how many of their customers they are pissing off:
    http://petitiononline.com/nforce2/petition.html [petitiononline.com]
  • If people with Nforce/2 motherboards really wanted to use an ATI card under GNU/Linux, google would've found the GART kernel patch. The Linux Kernel guys have had a working patch for a while now. I am getting around 2000fps with an Force2 board and ATI Radeon 9000 AGP on a pc I set up a month ago.

    NVidia have had a working NForce2 GART driver for some time, but refused to release it under now. Maybe I am wrong, but it kinda seems like NVidia wanted to delay so that people buy _their_ AGP cards - seeing that
  • I just hooked up an nforce2 motherboard into my main desktop PC yesterday, I grabbed the gart patch, applied it, reinstalled the nvidia drivers for my geforce3 and rebooted. Everything came up fine, the agpgart stuff seemed to work fine and glxgears was faster than with my previous motherboard, but then everything completely locked up after the machine had been up for a few hours (I was playing tuxracer at the time).
    DAMMIT!
    I have had agp disabled on this PC for a couple of years now because every damn frick
  • They say Xfree 3 4.2 and not 4.3 which I run on RH 9 does anyone know if they'll work or is there another driver I'm not seeing on the website.
  • I think they see supporting Linux as a good thing.
    I have found their driver for the Geforce cards to be stable, I have never had a problem personally.
    while I dont own an nForce2 board, I am happy that they released this driver. its another step in the right direction in my opinion.
    They cant release the code to the Geforce driver because the code they utilise isnt their code, but I wonder: will they try to get around that?
    There has to be a way around that issue. I forsee Nvidia releasing an open sour
  • I currently have an NVidia card, and NVidia drivers, and it is the sole reason for crashes on my machine.

    The display will lock, and I have maybe 30 seconds to SSH in and shutdown the machine, or it is hosed.

    Also look at this:

    maze root # /sbin/lsmod|grep -i nv
    NVdriver 1066304 10 (autoclean)

    A 1 meg kernel module? That must be all the cool special case code they have for cheating in benchmarks?

    Never mind the fact that I am purposely running an slightly older driver cos the new one seems less
  • Okay, so this brings to my mind a question about the miniITX boards by VIA. These are very small (170mm x 170mm) boards with basically everything included (video, sound, network, etc.), and are very low power (usually no active cooling, even for the CPU).

    Do these things work well with Linux (especially the embedded video, sound, & networking)?

    I'm planning on building a little box later this year with one of these things, and I was planning on using Linux, little suspecting that the driver issue was st
  • buying a Radeon, after how well nvidia's treated me as a linux user :).

  • Additional info (Score:2, Informative)

    by Gin'irochi ( 683665 )
    Hello.

    I'm actually the original writer of this story, however at the time of writing, I hadn't made an accounbt on /. yet (I'm such a lurker. ;)

    Anyway, I see from the comments people are having trouble with the GART driver (Getting DRI to work with a Radeon, etc.) So I will now post some more information.

    My setup is:

    • Asus A7N8X
    • Radeon 9700 Pro
    • GART patch applied to vanilla 2.4.20 kernel with a fresh build
    • fglrx 2.9.12
    • XFree86 4.3.0

    I've tested this configuration both on Gentoo and Debian Sid.

    The

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close