Slashdot Mirror
nForce2 GART Driver Finally Released For Linux
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.
because it is not possible to run a radeon card in DRI-Mode on an nForce(2) Motherboard
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.
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?
Bram Stolk http://stolk.org/tlctc/
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...
/. no-no) but they are better performance-wise than the open-source ATI DRI drivers...
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
_CMK
Bad spellers of the world untie!
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...
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
- Otaku no naka no otaku, otaking da!!!
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.
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.
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?)
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.
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. Have a look around while you're there, its an excellent source of information and we'd really love you to add to it.
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.
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.
"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 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.
It seems this guy has pasted this piece of crap before: http://slashdot.org/comments.pl?sid=67877&cid=6220 788
Founder of Mirror Moon - Tsukihime Game Trans
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.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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
"Oooh, does that mean we get to kick some puffy white mad zionist butt?"
First, before downloading anything you need to read and accept this license: http://www.nvidia.com/view.asp?IO=nv_swlicense
[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
|*
|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND
|* CONFIDENTIAL
|* TO NVIDIA, CORPORATION. USE, REPORDUCTION OR DISCLOSURE TO ANY
|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA CORP.
|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT
|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED
|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS
|* FOR A PARTICULAR PURPOSE.
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 '^[+-][^+-]'
+#ifndef PCI_DEVICE_ID_NVIDIA_MCP2_AUDIO
+#define PCI_DEVICE_ID_NVIDIA_MCP2_AUDIO 0x006a
+#endif
+#ifndef PCI_DEVICE_ID_NVIDIA_MCP3_AUDIO
+#define PCI_DEVICE_ID_NVIDIA_MCP3_AUDIO 0x00da
+#endif
+ {PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_MCP2_AUDIO,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, NVIDIA_NFORCE},
+ {PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_MCP3_AUDIO,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, NVIDIA_NFORCE},
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
\\Uriel
"When in doubt, use brute force." Ken Thompson