Slashdot Mirror
NVidia Releases Linux Drivers Supporting 4K Stacks
Supermathie writes "NVidia has finally released drivers for their chipsets and the 2.6 kernel that support 4K stacks. That means compatability with Fedora Core 2 kernels, people! View the README, visit their driver page, or download the package."
For me the best way to test these new drivers is to play Enemy Territory
One of the best online FPS games and it's free-as-in-beer.
Keep up the good work NVIDIA.
http://www.kubuntu.org/
It seems that this driver's OpenGL headers are a little buggy, but the solution was given by NVIDIA employee in this thread at nvnews.net forum.
http://lwn.net/Articles/84583/
See you, space cowboy...
I've been testing these drivers under Fedora Core 2 for a while, and they appear to work flawlessly.
Thad
I love Mondays. On a Monday, anything is possible.
For people who are building home theater PCs for things like MythTV, this is a major step forward. The last release that supported overscan (so that a TV image doesn't have black stripes on the sides) was many releases back (version 4363). This release not only supports Linux 2.6 with 4K stacks, but has overscan and interlace support, making it ideal for TV and HDTV display.
I know ET Pro is a addon for ET, but it seems like every server uses it.
It's an essentially obscure change they made in the 2.6 Linux Kernel. The idea was that the smaller stack lets you run more threads and perform better under higher IRQ loads. In reality, since pages are 4KB anyways, and most processors not only swap but also cache memory in 4KB pages, if the stacks don't actually use more than 4KB there's no advantage to artificially limiting them--the other memory doesn't really even need to "exist." It also required rewriting and reworking lots of things, such as these NVidia drivers, that assumed the stack size would be much larger than 4KB.
You can turn off the 4KB stack and go back to the default behavior by recompiling the kernel with the proper option set, but default Linux distros based on 2.6 all use (to the best of my knowledge) 4KB stacks by default.
Are there any video card manufacturers left who release other than binary only drivers?
...with the latest 2.6 kernels, simply turn off 4K stacks. But hey, now it's not necessary. Yay.
4k stacks are a good thing, a first step for Linux to support an insane amount of simultaneous processes on the system.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
this is a cut/paste of this article. Unless you actually wrote it, don't copy with no reference.
I submitted this story last night, and it didn't get posted.
Because the slashdot staff is dumb and retarted.
>They might have a slightly different perspective.
Yes, the IBM PC XT was a complete POS that couldn't compete with anything else out at the time. Almost nobody used it, apart from a handful of people. That garbage computer didn't even include a decent sound system, for crying out loud!
Then the clones came.
And the XT architecture became popular.
And IBM sold more PCs than they ever thought possible.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
I'll karma whore, since I read the article linked above.
If you allocate memory in 8k stacks, the kernel's got to find 2 pages of memory together. Which I guess gets to be a pain as uptime increases. Since memory pages on most hardware are 4k, it's easy as pie with 4k stacks. Plus, you separate some of the kernel stuff like software interrupt handlers to their own stack (I think that's what it was), hopefully making the system more stable in the process.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
OK... If you're a programmer, you know about stacks; they've been almost THE canonical way to allocate space for the broad family of "Algol-like languages" since the classic reference on implementing Algol 60. If you're not a programmer... you've seen those stacks of plates at cafeterias and restaurants, or of cups at the convenience store? The important property they have is LIFO (last in, first out). Think of each plate as a place where you can write some information. A function is run, it grabs a few plates for the things it needs to remember. When it is finished, it puts the plates back (you can only take an anlalogy so far, of course--if you put your plates back right away at the cafeteria, you'd gross people out). As long as there are enough plates left, it doesn't care who else called it, or how many callers came before it. All it needs to know is to go to the stack and get the number of plates it needs.
When you make a system call, it typically executes on its own stack, separate from the one you get for user state. The question is, how big should that stack be? It constrains how deeply nested you can get into function calls while in system state and how much space they can chew up for local variables. Until recently on Linux it's been 8K bytes (think 8192 plates), but they switched over to 4K, only half as much space (or half as many plates).
Some drivers as written count on having that whole 8K of space to play with, and they have to be rewritten. Since nvidia provides neither an Open Source driver nor sufficient information to allow anyone else to write one, however, it means that we have to wait until they deign to make that change. Fortunately, they've gotten around to it.
so finally nvidia got its act together. i wonder what took them so long?
They are still ahead of the game with Linux compared to ATI. ATI only just got Linux drivers out a few months ago. NVidia has had Linux drivers for at least around 2-3 years now (I didn't really care about it before then), this is just about them getting the 2.6 kernel drivers (and new chipsets). Also, to my understanding, ATI's Linux drivers arn't all that good, and they have yet to support the 2.6 kernel.
So really, if you want a brand name video card that supports Linux, NVidia is the way to go (at least for now).
I hope ATI can catch up to compete because their current Linux drivers are terrible. I am disappointed. :(
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
...is another important thing :) Finally, proper 32bit ioctls and libraries, no more mixing 32/64 bit releases and trying to use indirect rendering.
Btw, that was done for DRI drivers quite a while ago - talk about the usefulness of having access to the source code. And no, they aren't that useless - you can still play UT2004 with them, although it won't look as good(and I didn't notice much difference, except for performance, in ET(btw, for some reason, my FX5200 is _way_ slower while playing on radar/battery maps in ET than in any map in UT2004)
There is magic in their drivers, and it is explained EVERY SINGLE TIME NVIDIA GETS MENTIONED HERE. It's called a special OpenGL license from SGI and it's also some special in-house code.
Try to remember it this time, it's only the 400 millionth time it's been mentioned.
I currently use a Dell Inspirion 8200 laptop for Linux with an older GeForce 4 Go, and I swapped in an ATI M-9, and I lost the ability to send the video signal to my external monitor. ATI has a long ways to go to catch nVidia. nVidia isn't 100% perfect, but if you want to play 3D accelerated games with minimal hassle, you use nVidia. This is on Mandrake 10 also. Maybe in 5 years ATI will have something generally useful...
Let's hope ATI follows suit.
It took 2 third party patches and a recompile to get it their driver to install on Fedora Core 2, and it still crashes WineX.
All that we see or seem is but a dream within a dream.
Your point in the first paragraph is well taken. Second paragraph too, but I really don't think there'd be that much of a difference. ;-)
But:
You really can't revise the nv drivers because they're compiled binaries. Nothing is stopping you from modifying them except the little thing that it's not accessible code to modify, since if it was this thread wouldn't have started.
The nv driver is not the official release from NVidia. It's a part of XFree86 (and now X.org), and is available under the MIT license or whatever they call it.
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON 9600 XT Generic
OpenGL version string: 1.3 (X4.3.0-3.9.0)
Linux ws 2.6.7-ws4 #1 Sun Jun 20 17:57:30 CEST 2004 i686 GNU/Linux
And, ATI has released linux drivers for a while, not just "a few" months, however there was (iirc) no official driver support for non-FireGL cards for a while, even though the drivers for the normal Radeon cards was included in the binary FireGL driver package.
You were trying to do very intrinsic things to Linux and then complaint. Such low level changes are hard to do on any system. The good thing - they are unnecessary for novice user. For you, as an inexperienced linux user, I would recommend to use FC2 installer and then just use the system. It has web browser/office suite/etc. Read Fedora support site - some things(NTFS) you were trying to do are not supported by Fedora yet. This would save you some time.
Actually Linus dictated that the newer versions of the 2.6 would only allow 4k stacks and will require you make your own patch to disable it. Red Hat just decided to default in FC2 from the start rathre than deal with weaning users off later.
Can I get an eye poke?
Dog House Forum
Yes, except that if you use something other than Linux/x86 (e.g. Linux on ppc or sparc), you can kiss goodbye to 3D acceleration and Xv extensions (very useful for mplayer and xine), even on a piece of shit 5 year old TNT.
Yes but who cares? I don't want driver source code, I want chipset specs, so I can write my own. There is no issue with patents for chipset specs unless the patent license EXPLICITLY disallows specs being published. There is no reason to do this, as it's a patent, the patent has to be published in the first place so there is nothing to be gained.
Actually, this is the idea.
Huh? There certainly is a difference between what I described and how the driver is currently working. Maybe my suggestion would require changes of the binary code and/or the X server, but it certainly should be possible.
The interface with the kernel is open source
That statement doesn't make any sense. You can say the interface is open, and you can say the kernel is open source. But an interface is something more abstract than a piece of code. Of course when talking about interfaces to the kernel it is important to keep in mind, that there are two different interfaces. There is the user/kernel mode interface. This API complies (mostly) with various standards: Posix, BSD, Single Unix specification, SysV. But the standards only specify the API, not the ABI which is Linux specific. This ABI is kept as stable as possible even across kernel versions. But this interface is not really important when discussing kernel modules. The functions kernel modules can link against may change, and no attempt is made to keep the ABI stable, only the API is kept stable within each major version as long as the API doesn't turn out to be a major problem. This API is however the same across multiple CPU architectures (unlike the user/kernel ABI discussed before). But this really means that if you want to ship a Linux kernel module, you have to ship it as source. Because it is only at the source level there is a well known interface. A fixed ABI is just not possible, just the differences between CPU architectures is enough to make it impossible, but in addition some data types in the kernel are different depending on the options. And finally there are stuff like the 4K stacks where the current macro had to be changed.
the closed source code is a binary object that gets linked into the module.
And that is a problem. Not only does it only work on one architecture, but it makes assumptions about the kernel, which may not be satisfied. The amount of stack space is not the only problem here. The code can break the kernel in various ways, which means you can no longer trust your kernel.
context switching to a different privilege level would only hurt performance.
Some years ago I did some meassurements of this on a computer, that is now five years old. It could do one million switches from user mode to kernel mode and back again per second. I believe newer machines can do a bit more than that. I guess very few people have a monitor refresh rate of more than 100Hz. That means you will have time for about 10000 switches. Of course you can't use all your CPU time just to be switching, but let's say you can do a single frame with less than 1000 switches, then you certainly wouldn't have a performance problem. And if more than 1000 switches are required to do a single frame, then you have a broken design that needs to be fixed. It is not the amount of data needing to be transfered that is a problem, because you could either map board memory directly into the user mode process, or (a litle more complicated) do DMA directly to user space. So I won't believe your talking about performance problems, until I see a proof that it can't be avoided.
NVidia has been so far quite open source friendly when it comes to producing drivers.
NVidia have not really been that friendly. They may seem friendly when compared to other 3Dgfx manufacturers. This really just means there is a market, where no vendor give a damn about their customers. I hope some vendor will realize this, because if they do, and make the product the customers want, then I believe they can make some money.
Do you care about the security of your wireless mouse?
Actually, this is the idea. The interface with the kernel is open source; the closed source code is a binary object that gets linked into the module.
That works great if you can guarantee separation. Otherwise debugging is a nightmare, knowing that there are some black boxes in your system which can manipulate the whole system.
Sorry, user mode doesn't really make much sense here, drivers need full hw access and context switching to a different privilege level would only hurt performance.
Right, that wouldn't work too good - but if everything runs in kernel mode then there is no border control between the driver and the rest of the kernel. The driver has to be trusted to play nice and not to fuck up the kernel data structures, because there's nothing that can stop him doing that. It would be different if the driver ran in user mode, because then the driver would throw segmentation faults and the like if it does something illegal.
The conclusion is that source code should be available for everything that runs in kernel mode.
No muchie to add really folks, just this linkage....
b ef ffec2e9be58fa181ba97b1c627de8&f=61
h ow to/
;-)
:-)
http://www.rage3d.com/board/forumdisplay.php?s=
http://www.rage3d.com/content/articles/atilinux
Xcuse the length of the URLz but the Nvidia FUD needs to be corrected....
Now maybe ATI will send me a new card
Enjoy folks & Peace.
Greek Geek
It also mentions something about interupts that I don't understand.
The problems with interrupts is, that you don't have much control over when they arrive, and when they do arrive, they need stack space. So with interrupts interrupting each other, you can quickly use a lot of stack space. If you were very unlucky, you could probably overflow even a 16KB stack that way.
So you would either have to disable interrupts or make sure there were always enough stack space to take an interrupt. Disabling interrupts is something we don't want to do for more than a few nanoseconds, so something have to be done.
With 4KB stacks this problem become even worse, but there is a solution. Assume we need to be able to handle for example five interrupts at the same time and each of them need 3KB of stack space. With the traditional approach, we would need to always leave 15KB of stack space in every thread. But we are never going to need all of that, because at any time there is only one thread executing on each CPU.
Interrupt stacks means that rather than using the stack of the current thread, we simply switch the stack pointer to a different stack only used for interrupts. We will still use a small amount of stack space in the current thread, but certainly less than 100 bytes, and only for the first interrupt. This means that the thread stack no longer needs to leave free space for some unpredictable amount of data.
The kernel design requires the kernel stack of every thread to have exactly the same size (and a power of two). The current macro on x86 is one piece of code relying on this. But within an interrupt current doesn't make any sense. So it should be possible to make the interrupt stacks larger than the thread stacks. That way we can have a few large interrupt stacks and a lot of small thread stacks. This use less memory than a lot of large thread stacks. The number of thread stacks just have to be one pr CPU or one pr handler depending on your design.
My system currently have 1 CPU, 12 interrupt handlers, and 101 threads. Which means that saving 4KB per thread and then creating a single 16KB interrupt stack would save a lot of memory.
Do you care about the security of your wireless mouse?
Unlike user space stacks, you cannot* automatically increase the size of the kernel stack when it overflows, because there would be nowhere to place the parameters to the page fault exception handler (the parameters are put on top of the kernel stack). Therefore, the kernel stack must have a fixed size, and if you make this 4 KB instead of 8 KB, you save that amount per process.
*) Actually you can, if you use some obscure technique involving an extra task select segment and a voodoo doll. I assume they don't use this approach because it's too complex or slow.
The world will end in 5 minutes. Please log out.
Snipped from the driver's README:
Personally I haven't noticed any difference, but then I've got some AGP issues, so YMMV.
RegardselFarto
Opteron: 4
Alpha: 8
Sparc64: 8
Itanium: 4, 8, 16, 32, or 64 (usually set to 16)
You can always double-up in software. The VAX has
1/2 kB pages (512 bytes), but the Linux port puts
8 of those together to make a 4 kB page.
The 680x0 processor lets the OS choose the page
size to be pretty much anything.
I'm fully aware of the liscensing issues and the whole PITA that doing that for them would involve, but here's the thing:
Right now, I have to "dual-boot" my X depending on whether I want good RENDER performance or want to run OpenGL stuff. My webpage has a theme I really like that my boyfriend made. The background is an animated GIF of rain falling. I'll get 100% CPU usage on my Athlon XP 1400+ and my browser will become practically unresponsive using the "nvidia" driver, but when I switch over to the open source "nv" driver, it does maybe 15% CPU usage -- just like in Windows.
Mesa as absolutely unacceptable for doing 3D graphics. Even a simple shooter I'm working on called "Blammo" for the time being will chug to about 5 fps under "nv."
Now, if only we could bring the features of the "nv" driver and the "nvidia" driver together.
I think the main problem with "linux being ready for the desktop" (as though it isn't -- all that linux really lacks is the ability to twist the arms of OEMs) is that if you want to use certain hardware, you can't get optimal drivers. This is, of course, a vicious circle, because NVidia could fix the problem I have in the "nvidia" driver tomorrow if they wanted, but they won't, because the target market is too small to waste their time.
I might be willing to pay $300 for a brand-spanking-new ubervideocard once the X drivers get fixed, but there are also about 300 other people willing to do the same so long as the Windows drivers stay working.
Perhaps the solution therefore is to change the liscense on the "nv" driver so that NVidia can use the code that's already out there. It makes the authors of the "nv" driver saints, and NVidia stays an evil corporation, and I get Windows-like performance out of my hardware in X, and everyone's happy.
Join the Slashcott! Stay away entirely Feb 10 thru Feb 17! Close all tabs to prevent autorefresh!
No, ATI was a "full supporter" of Linux for many years. Mostly, they gave the specs for their cards to the XFree86 NDA mail list, and the XFree86/DRI/etc developers produced top notch linux drivers for ATI cards. The old joke use to be you could tell how bad ATI's own (windows) drivers were by running the same card that performed poorly in windows and seeing how much ass it kicked in Linux. There were a few cards ATI developed open source drivers for in addition to giving the spec. Then for various reasons, ATI stopped providing specs for their cards and started releasing binary only drivers. ATI provided specs for all cards up to the Radeon 9200. It should be noted the Radeon 9100 (which is a rereleased Radeon 8500) is faster than a Radeon 9200 and is to the best of my knowledge the best graphics card fully supported by open source drivers to date. DRI's ATI Radeon details
This looks like a pointless argument, but I'll give it a shot. Just to make it clear from the beginnig, I think you're too extreme on this. I'm just trying to play the devil's advocate a bit to balance the field.
... well, you get the idea. The consequence is that, in a givn field, the underdog is more likely to have open drivers/specs. This happened to NVidia w.r.t. the nforce chipset: when they started losing ground to Via, opening up at least part of the spec made sense. In the video segment, the competition is too fierce, so both NVidia and ATI go closed-source for now. Heck, look just at CPU chipsets: AMD actively encourages third-party chipsets, while Intel would rather sink the competition. Look at how much time it took Intel to come up with Linux drivers for Centrino (and they probably did it mostly because of the planned push into Linux laptops with IBM) - and Intel is supposed to be a Linux backer these days.
Companies are in business for the money. Love it, hate it, that's the goal. If keeping code closed brings them an advantage, most will do it. If opening the code brings the advantage
Now, back to the video drivers issue. In the blue corner, NVidia. In the red one, ATI. Whom would you call 'more open-source friendly'? Bear in mind that, lately, Linux rendering is mainstream and offloading some processing to the gpu seems like the next interesting trend - thus, there's a market for Linux drivers. So both players release Linux binary drivers. NVidia has been doing it for a long time now, ATI just started (if you're not counting half-baked, unsupported drivers). But wait, NVidia has drivers for some apparent useless platforms, like IA64, AMD64, or FreeBSD/x86. Not much of an economic incentive there. So why do they do it? Or, conversely, why is ATI not doing it?
My point is: here's a corporation that spends some resources to provide a number of people with drivers without much economic gain (I don't really think the number of GF cards bought for playing 3D games on FreeBSD or Linux/IA64 covers too much). In my book, that makes NVidia more open-source friendly than ATI. They are in it for the money, sure, but also a little more than that. Also, remember that they were providing Linux drivers when Linux was a lot less used and NVidia was the top graphics dog, which again was a refreshing difference of attitude from the mainstream.
Yeah, I know, I'm biased here. I'm probably just happy I get 3D accelerated graphics on my Linux/AMD64. I could have had to stick with just 2D, but there was this one vendor that had drivers from almost day one. That does not make them holy or anything *insert bitching about nforce3 drivers here* but it's sure nice to have a working option instead of none from time to time.