Forgot your password?
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

Comments Filter:
  • Re:Radeon owners? (Score:4, Informative)

    by heckpart (683490) on Sunday June 22, 2003 @03:56AM (#6265876) Homepage
    because it is not possible to run a radeon card in DRI-Mode on an nForce(2) Motherboard
  • Re:Radeon owners? (Score:5, Informative)

    by cheshiremackat (618044) on Sunday June 22, 2003 @04:03AM (#6265894)
    Because, before this patch, under linux you could only run an Nvidia based AGP card... Nvidia (used to) only supply an NVAGP module that would not work with ATI products...

    Essentially this meant that if you ran linux under nforce you were stuck to an all Nvidia lineup...

    The only hiccup is that IMHO Nvidia has better drivers under Linux than ATI... true, Nvidia's are closed source ( a /. no-no) but they are better performance-wise than the open-source ATI DRI drivers...

    _CMK
  • by bajo77 (632115) on Sunday June 22, 2003 @04:03AM (#6265895)
    Linux's lack of Token Ring support and the fact that we were unable to defrag its ext2 file system

    Information on token ring support for linux is available at www.linuxtr.net

    As far as I know ext2 does not really need to be defragmented as performance is not affected as much as it is on fat*/ntfs. Also there are ways to defrag it.

    So you can imagine our suprise when we were informed by a lawyer that we would be required to publish our source code for others to use.

    You switched to Linux without reading the copyright? Not to mention that you only need to release the source code if you modify existing gpl'ed projects.

    I think the biggest thing keeping Linux from being truly competitive with Microsoft is this GPL...

    Now you're just trolling, this is offtopic anyway. The only reason Linux has become successful is because many people add to it...
  • 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 :)
  • mod parent down (Score:4, Informative)

    by DMDx86 (17373) <<news> <at> <fortbendisdsucks.com>> on Sunday June 22, 2003 @04:05AM (#6265904) Homepage Journal
    In the past, only NVIDIA cards could be used on nForce2 mobos due to the fact that you could only get a nForce2 AGP-GART driver packaged with the NVIDIA linux video drivers. The fact that the GART driver has been seperated from the video drivers means ATI Radeon and other cards can now work with nForce2 chipsets under linux.
  • Re:Closed-Source (Score:3, Informative)

    by cheshiremackat (618044) on Sunday June 22, 2003 @04:12AM (#6265925)
    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 reason for keeping the Driver code closed is b/c there is some "trade secrets" that could be gleaned from an open driver release...

    _CMK
  • 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.
  • by Anonymous Coward on Sunday June 22, 2003 @04:22AM (#6265958)
    You either have no knowledge on Free Software licenses, hire incompetent lawyers, or are deliberately trying to spread FUD (I can assure the latter will not work on /.)

    (1) The "GPL compatible licensed" terms only applies to _distributed_ work. If your organiztion really are doing internal only work, you do not have any obligations to make available your source or binaries.

    (2) Compiling code with GCC does NOT make your code automatically GPLed (how/where did you dig up lawyers like that?)

  • 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.
  • Re:Actually... (Score:5, Informative)

    by Elladan (17598) on Sunday June 22, 2003 @04:26AM (#6265969)
    The New nvidia graphics installer (4369) comes with a new installer that will either d/l the appropriate pre-compilled driver, OR d/l the sources and compile a driver for you... all you need is the kernel-source installed for your current kernel...

    That's not the driver it's recompiling. It's recompiling a wrapper layer around the driver that interfaces between it and the kernel.

    The actual driver is completely closed-source. It may work with multiple kernels as long as the wrapper compiles, but there's no guarantee of that and it still can't be debugged or audited for security or anything.

  • 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.
  • by 101percent (589072) on Sunday June 22, 2003 @04:32AM (#6265979)
    "Furthermore, after reviewing this GPL our lawyers advised us that any products compiled with GPL'ed tools - such as gcc - would also have to its source code released. This was simply unacceptable."

    This is simply untrue. Many non-free systems are compiled using GCC. Many propreitary systems [openbsd.org] are built using the Gnu Compiler Collection, and I have never heard of the Free Software Foundation claiming that they must release their code. I think this is either a misinterpretation by your lawyers or general just fear, uncertainty, and doubt on behalf of your company.

    "I think the biggest thing keeping Linux from being truly competitive with Microsoft is this GPL. Its draconian requirements virtually guarentee that no business will ever be able to use it."

    The GPL is hardly more draconian than the Microsoft EULA. Furthermore, the GPL is clearly not about companies. The GPL is about giving freedom to the user.

    "Everyone was very pleased with Linux, and we were considering using it for a great deal of future internal projects."

    Your comment significes the overwhelming sensibility of sharing code. All the public resources that have gone into creating the myriad of propreitary products is generallyh wasteful. Their is no point in trying to re-invent the wheel. Their is no point in not sharing generally useful technical information.

    I personally admire what your company did in contracting to modify Free software for specialized purposes. This is exactly how Free Software would benefit to our economy, especially for developers such as yourself. The only reason that things like Microsoft EULA's exist is so that someone can take away the freedom of their users and exhibit a system of power over them as people. The arguement that companies must protect their intellectual property is flawed because the money that they make generally doesn't go into paying for the costs of distrobution. It goes into things like making Bill Gates a very rich man. That's a system not at all concerned with compensating the developers, once you make an analysis and really think about it.
  • by chendo (678767) on Sunday June 22, 2003 @05:02AM (#6266033)
    It seems this guy has pasted this piece of crap before: http://slashdot.org/comments.pl?sid=67877&cid=6220 788 [slashdot.org]
  • 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.

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

  • 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]
  • by Anonymous Coward on Sunday June 22, 2003 @06:04AM (#6266158)
    That concerns binary-only drivers. nForce USB, IDE and AGP features are/will be supported by standard Linux kernel.
  • Re:Closed-Source (Score:5, Informative)

    by Simon Kongshoj (581494) <skongshoj@on[ ]le.dk ['cab' in gap]> 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.

  • Re:Radeon owners? (Score:2, Informative)

    by Boltronics (180064) on Sunday June 22, 2003 @07:30AM (#6266326) Homepage
    nVidia drivers really are a lot better here, but I'm sticking with ATI.

    With this MB under Gentoo with a Radeon 8500 64MB and fireGL I get 2200FPS in glxgears, but the same configuration using an nVidia MX440 64MB I get 2600FPS. Using otherwise exactly the same setup. The XFree86-DRM DRI driver for the Radeon gave 1800 BTW.

    Now under Windows XP with MadOnion 3DMark2001SE, the Radeon kills the MX440, although I can't remember the exact scores.
  • by meowsqueak (599208) on Sunday June 22, 2003 @08:12AM (#6266417)
    In terms of performance ("faster"), it really depends quite heavily on several factors, including your hardware and the game itself. Wine(X) is a compatibility layer rather than an emulator, so corresponding Win32 API calls in the game are handled by the wine subsystems. I imagine generally this would be a little slower than the native win32 environment, since these routines are further 'backed' by the native environment (X11 etc). It's like adding an extra function call (at least) to each one the game makes. The faster your CPU is, the less impact these additional layers of execution are going to have.

    Programming the hardware rendering pipeline is done via a DirectX-compatible layer (I guess not for OpenGL games?). If you have a high end video card (with drivers) and your Linux kernel is friendly with your north bridge, then rendering speeds are probably around about the same as in Windows.

    So, final performance is really going to depend on where the bottleneck is. If the game is limited by your video acceleration hardware, then it's probably going to run about the same in Linux as in Windows, given your hardware has similar kernel and driver support in both. If the major bottleneck is with the CPU (e.g. a complex physics engine or large amounts of computation) then, based on my previous comments, it makes sense to expect the game to perform worse in the Linux environment.

    I've played such things as UT, UT2003 in Linux 'natively' and I found the performance comparable to the same game running in Windows. Under WineX I've played around with RollerCoasterTycoon, Jagged Alliance 2, Fallout 2, Jedi Knight 2, and a few others. I found all of these games ran slower in Linux than in Windows. However, not a *lot* slower, just noticably slower. They were still technically playable.

    Which brings me to an interesting point. By far, the most problems I've had with WineX haven't been due to graphics, sound, performance or even copy protection. The biggest problems I've had *by far* have been to do with my mouse. In RCT, the right mouse button refuses to work properly; in JA2, a single click ends up a double click (which is a lot more annoying than it might sound - especially with checkboxes!). Getting my Microsoft joystick working hasn't been fruitful (I don't even know for sure that it's possible). It's a bit of a disappointment to successfully install your favourite game with WineX, fire it up to see the wonderful and familiar graphics, hear the emotion-stirring music, only to discover you can't click on anything or the keyboard doesn't work.

    WineX is an interesting project and one I hope continues to improve. However, it only takes me a minute or two to boot into Windows and fire up something for my 'fix'. At the end of the day, I'm not too bothered if I'm gaming in Windows or Linux, as long as I get to have some fun.

  • Re:Not GPL (Score:2, Informative)

    by Boltronics (180064) on Sunday June 22, 2003 @08:31AM (#6266452) Homepage
    Straight from the documentation:

    "The network driver provided by NVIDIA is subject to the NVIDIA software license; the license is available on the NVIDIA website, and is included in this package. By using this software, you are agreeing to the terms of the license. The rest of the software is provided under the GNU public license, which is also included in this package."

    The 2.4.20 kernel patch for AGP (which is the topic of discussion) was released under the GPL.
  • Re:Not GPL (Score:3, Informative)

    by samhalliday (653858) on Sunday June 22, 2003 @09:26AM (#6266551) Homepage Journal
    RTFA and RTFC (code)!!! did you even bother downloading before posting? the license file explicitly states that the kernel patch is under the GPL and that the binary drivers are under nvidias license.
  • Re:Radeon owners? (Score:2, Informative)

    by TerryMathews (57165) on Sunday June 22, 2003 @12:44PM (#6267602)
    GLXgears != benchmark. It takes advantage of no hardware features. Just pure pixel-pushing bandwidth.
  • Additional info (Score:2, Informative)

    by Gin'irochi (683665) on Sunday June 22, 2003 @05:51PM (#6269205)
    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 DRI drivers do indeed work, as you can see here:

    cthulu root # glxinfo
    name of display: :0.0
    display: :0 screen: 0
    direct rendering: Yes

    as well as here:
    cthulu root # fglrxinfo
    display: :0.0 screen: 0
    OpenGL vendor string: ATI Technologies Inc.
    OpenGL renderer string: Radeon 9700 Pro Athlon (3DNow!)
    OpenGL version string: 1.3 (X4.3.0-2.9.12)

    The fversion of FireGL drivers I am using are indeed 2.9.12 -- these are not currently available on ATI's website. This thread [transgaming.com] on transworld gaming's forums have links to tarballs for the FGLRX 2.9.12 drivers for both XF86 4.2 and 4.3. Dont mind that the thread actually says 2.9.8, the links are current.

    Other than the updated drivers, I hadn't done anything special to get the GART driver and the R9700 to play nice together. However, it did take me 3 straight days of searching via google to figure out that the Kernel does not support AGP 3.0 in 2.4.x implementations, so the easiest workaround is to simply disable it in the bios as I mentioned in the story.

    run fglrxconfig, generate your config file, restart X, you're good to go.

    On another note, yes indeed -- if you read the new license carefully, the .diff file is released under the GPL. No, the net driver is not, nor do I believe the sound driver is either, but I may be mistaken. I really dont give a damn what liscense is used as long as my hardware works. :)

    As for the patch to the radeon driver that supports AGP3.0, I'll have to check it out. Sounds interesting.

    Oh, by the way:
    cthulu root # glxgears
    20234 frames in 5.0 seconds = 4046.800 FPS
    23297 frames in 5.0 seconds = 4659.400 FPS
    23300 frames in 5.0 seconds = 4660.000 FPS
    23298 frames in 5.0 seconds = 4659.600 FPS

    Hope this helps someone out there. :)

Serving coffee on aircraft causes turbulence.

Working...