I'm glad you were marked insightful for that comment. I assume that means that, although illegal, it's perfectly moral for me to come to your house and take anything I want?
The NVidia binary-only driver runs only on particular kernel revisions, and does not allow the user to switch between SMP
and UP operation.
I think you're incredibly misinformed here. Our driver runs on pretty much every kernel since ~2.0, and the kernel interface source code is provided to get it running on any kernel we don't directly support (which often happens with the 2.4 test kernels). Users are also able to recompile the module to target their UP/SMP kernel.
This is due to top reporting virtual memory usage, not just physical memory usage. This causes things like mmapped registers and framebuffers to be considered "used memory".
Our nvidia drivers mmap both framebuffers and registers (maybe a little excessively, but it won't hurt anything). This isn't "real RAM" being used, but only virtual memory.
A couple of functions that convert memory address, for example from user virtual address to physical address. They're actually code that probably belongs in the kernel proper, and that many OSS drivers end up reproducing anyways. (~100 lines of pretty straight-forward code).
compare the nv.c file included with the drivers with any version of bttv.c
For the record, I do work at SGI, so am obviously biased. But I have to respond with a huge "WTF" to this. Some of your points are correct, but some are so far from wrong.
1. SGI is moving to Linux because we don't have the expertise to support Irix.
Wrong. We have lost many, many people with lots of experience. But the move to Linux has nothing to do with that. The move to Linux is because it's getting harder and harder to get ISVs to port their apps to Irix. Someone mentioned earlier in this thread that it took forever to get Seti@Home under Irix. That is the exact reason.
2. Porting XFS is a last ditch effort by SGI because we don't understand the source code.
Again, far from true. Linux doesn't have a journaling file system, which it badly needs. If we want to rely on Linux, we have to see that need fulfilled. Throughing out random code we don't understand just makes no sense. Especially when you consider a heavy IP-cleaning process is involved before we release it, which means *somebody* has to understand (or learn) the code. That process alone offsets any "let others figure it out" possibilities.
3. The Microsoft deal.
You may be correct that dealing with Microsoft is akin to dealing with the Devil. But to say that OpenGL died as a result is rewriting history. Just before the deal was signed was the legendary D3D vs. OpenGL war. What was the D3D's side biggest point? No OpenGL drivers for any PC boards. Why? Microsoft stalled on registering the ones submitted by PC vendors. Nowadays, how many PC boards have OpenGL drivers? Every single one. And as vendors look at cross-platform games, OpenGL is a no-brainer. If anything, the deal allowed OpenGL to fly in under the radar and get better support.
4. You're probably right that the Cray merger was a huge mistake. But I don't know too much about that area of the company, so I'll steer clear.
Sorry, but too many of your comments came across as the worst possible readings of current happenings, and I just wanted to provide some counters.
I do think there is a limit in memory mapping or bus mapping or something silly like that. It just happens to be 3 or 4. But I could be wrong or mis-remembering.
Also, you run out of IRQs quickly, but I don't recall if an IRQ is used per drive or controller. I think things like Promise's IDE HW RAID uses some form of IRQ overlays, using one IRQ for multiple drives/controllers.
Actually, I *believe* you can have 3-4 IDE controllers on a single mobo. Most only have 2 for economic reasons, and the bios only controls the 2 on the mobo. There are adapter cards that can be plugged into the motherboard, which may have seperate bios setups (like SCSI), I'm not sure.
He said 3 controllers. Having RAID with multiple drives on the same IDE controller is a waste. Unlike SCSI, IDE can only access one drive on a controller at a time.
The point of RAID is to read from multiple drives at once. Having those disks on the same IDE controller means you only read from 1 at a time, basically killing any speed benefits from RAID.
> By releasing already-written GPLed drivers, NVidia jumped to the top of the pack. Esp. since they actually have decent Windows drivers if there are any games you still need to reboot for.
The driver isn't GPLed. It's an X-like license:
Users and possessors of this source code are hereby granted a nonexclusive, royalty-free copyright license to use this code in individual and commercial software.
Sorry, the initial post was refering to quake2 & q3test. THe numbers are very rough, for quake2 (640x480). Try it out, numbers are bound to vary somewhat. q3test is a bit slower, but will hopefully improve somewhat before long.
You should see roughly 15 fps on a 200MHz CPU, up to roughly 20-25 fps on a 400+MHz CPU.
Dim: $99 does not an Octane make!
on
SGI Name Change
·
· Score: 1
The 3d performance is actually far superior to a 3dfx card, if you run an application that's worthwhile.
PC 3d cards only accelerate fill rates, not geometry transformation. Quake is mainly large polygons with textures that takes advantage of the PC fill rate, while avoiding the geometry transformation problem. The Octane targets CAD work, and therefore much more focused on geometry transformations.
It may not be very impressive on a fill-rate game like Quake, but can push the 3d models displayed in game magazines around with hardly a sweat.
She's actually correct. Even on systems that are already 64 bit (solaris, irix, etc.), 32 bit binaries are used more. There's no need to use 64 bits worth of data, unless needed. Currently, only servers with large databases and file systems tend to use 64 bit binaries. Workstations and desktops won't need the 64 bit power, but if NT wants to attack Unix servers, they need 64 bits.
Slashdot Mirror
I'm glad you were marked insightful for that comment. I assume that means that, although illegal, it's perfectly moral for me to come to your house and take anything I want?
the difference is some other idiot wasted his money making a bad movie. With NASA, it's *my* money being wasted.
Regardless of my opinions of NASA, just pointing out the difference
out with one technology (audio/visual proof), in with another (forensics/dna).
There are now updated drivers at irc.openprojects.net#nvidia.
Use "/ctcp iCE-DCC cdcc list" to see a list of updated drivers.
Terence Ripperda
NVIDIA
This is due to top reporting virtual memory usage, not just physical memory usage. This causes things like mmapped registers and framebuffers to be considered "used memory".
Our nvidia drivers mmap both framebuffers and registers (maybe a little excessively, but it won't hurt anything). This isn't "real RAM" being used, but only virtual memory.
In short, it's unnerving, but harmless.
Terence Ripperda,
NVIDIA
A couple of functions that convert memory address, for example from user virtual address to physical address. They're actually code that probably belongs in the kernel proper, and that many OSS drivers end up reproducing anyways. (~100 lines of pretty straight-forward code).
compare the nv.c file included with the drivers with any version of bttv.c
For the record, I do work at SGI, so am obviously biased. But I have to respond with a huge "WTF" to this. Some of your points are correct, but some are so far from wrong.
1. SGI is moving to Linux because we don't have the expertise to support Irix.
Wrong. We have lost many, many people with lots of experience. But the move to Linux has nothing to do with that. The move to Linux is because it's getting harder and harder to get ISVs to port their apps to Irix. Someone mentioned earlier in this thread that it took forever to get Seti@Home under Irix. That is the exact reason.
2. Porting XFS is a last ditch effort by SGI because we don't understand the source code.
Again, far from true. Linux doesn't have a journaling file system, which it badly needs. If we want to rely on Linux, we have to see that need fulfilled. Throughing out random code we don't understand just makes no sense. Especially when you consider a heavy IP-cleaning process is involved before we release it, which means *somebody* has to understand (or learn) the code. That process alone offsets any "let others figure it out" possibilities.
3. The Microsoft deal.
You may be correct that dealing with Microsoft is akin to dealing with the Devil. But to say that OpenGL died as a result is rewriting history. Just before the deal was signed was the legendary D3D vs. OpenGL war. What was the D3D's side biggest point? No OpenGL drivers for any PC boards. Why? Microsoft stalled on registering the ones submitted by PC vendors. Nowadays, how many PC boards have OpenGL drivers? Every single one. And as vendors look at cross-platform games, OpenGL is a no-brainer. If anything, the deal allowed OpenGL to fly in under the radar and get better support.
4. You're probably right that the Cray merger was a huge mistake. But I don't know too much about that area of the company, so I'll steer clear.
Sorry, but too many of your comments came across as the worst possible readings of current happenings, and I just wanted to provide some counters.
Terence Ripperda
SGI
I do think there is a limit in memory mapping or bus mapping or something silly like that. It just happens to be 3 or 4. But I could be wrong or mis-remembering.
Also, you run out of IRQs quickly, but I don't recall if an IRQ is used per drive or controller. I think things like Promise's IDE HW RAID uses some form of IRQ overlays, using one IRQ for multiple drives/controllers.
Actually, I *believe* you can have 3-4 IDE controllers on a single mobo. Most only have 2 for economic reasons, and the bios only controls the 2 on the mobo. There are adapter cards that can be plugged into the motherboard, which may have seperate bios setups (like SCSI), I'm not sure.
He said 3 controllers. Having RAID with multiple
drives on the same IDE controller is a waste. Unlike SCSI, IDE can only access one drive on a
controller at a time.
The point of RAID is to read from multiple drives at once. Having those disks on the same IDE controller means you only read from 1 at a time, basically killing any speed benefits from RAID.
> By releasing already-written GPLed drivers, NVidia jumped to the top of the pack. Esp. since they actually have decent Windows drivers if there are any games you still need to reboot for.
The driver isn't GPLed. It's an X-like license:
Users and possessors of this source code are hereby granted a nonexclusive, royalty-free copyright license to use this code in individual and commercial software.
Sorry, the initial post was refering to quake2 & q3test. THe numbers are very rough, for quake2 (640x480). Try it out, numbers are bound to vary somewhat. q3test is a bit slower, but will hopefully improve somewhat before long.
You should see roughly 15 fps on a 200MHz CPU, up to roughly 20-25 fps on a 400+MHz CPU.
The 3d performance is actually far superior to a 3dfx card, if you run an application that's worthwhile.
PC 3d cards only accelerate fill rates, not geometry transformation. Quake is mainly large polygons with textures that takes advantage of the PC fill rate, while avoiding the geometry transformation problem. The Octane targets CAD work, and therefore much more focused on geometry transformations.
It may not be very impressive on a fill-rate game like Quake, but can push the 3d models displayed in game magazines around with hardly a sweat.
She's actually correct. Even on systems that are already 64 bit (solaris, irix, etc.), 32 bit binaries are used more. There's no need to use 64 bits worth of data, unless needed. Currently, only servers with large databases and file systems tend to use 64 bit binaries. Workstations and desktops won't need the 64 bit power, but if NT wants to attack Unix servers, they need 64 bits.