I'm interested, what chipset are you running it on? I've used NVIDIA's Linux drivers on the following configurations:
1) PII-300 Intel 440LX chipset - RivaTNT and GeForce2 MX. 2) Athlon XP 1700 + SiS 735 chipset - RivaTNT and GeForce2 MX. 3) Pentium 4 2000 + Intel 845M chipset - GeForce4 Go 440.
I've never had a crash on any of those machines that wasn't my fault (devel software:). I've also had a Duron 750 running the GeForce2 MX and the Athlon XP running a GeForce4 Ti 4200 under Windows, and neither of those machines crash either, even under heavy gaming. I heard that the NVIDIA drivers don't get along well with VIA chipsets, though, and some configs require manual tweeking of AGP settings.
Nonsense. Even compiling simple C++ heavily templated C++ software takes ages. Hell, even non templated software like KDE takes close to a day. G++ is just plain slow, there is no doubt about it. Of course, C++ is one best of a language to compile, so you can blame G++ entirely. That said, C++'s complexity at the developer end (especially with templates) can pay off a huge amount at the user end. Templates allow you to do "pretty" designs without sacrificing performance. It's a win-win for everybody but the compiler-writers.
The difference is that latency isn't as a big an issue in graphics. In regular code, there are lots of branches and whatnot that depend on the results of a memory access. In graphics (particularly with the frame-buffer) data is moved around in far larger chunks (for example, you'd bring in a large part of a texture at once, rather than just one or two words) so latency doesn't hurt as much. Also, I don't know if latency would be hurt very much anyway. The data is only compressed going over the bus. It's stored uncompressed at either side.
Actually, I don't play games. I do 3D work, scientific programming, and C++ development. However, that stuff requires just as much horsepower as gaming. But thanks for playing, anyway:)
It's Dx8'ish (even though it uses OpenGL) in that it uses features specified in the DX8 shader APIs. This means integer pixel pipelines, and small shader programs without loops or other flow control. This card offers full floating-point pixel pipelines, and support for complex shader programs with branches and whatnot. These features are requirements for being fully DX9 compatible.
As desktops shift to using the 3D engine for 2D, this problem will go away. I tried the EVAS demo the other day, and it blew me away. This *is* the future.
I doubt you know enough about GPU architecture to make that sort of bullshit comment. Graphics is a very simple, very parallizable system, when you get down to it. What matters, (assuming good drivers and adequate memory bandwidth, which isn't always the case) is clock_speed * pixel-pipelines. This has been the case since the Riva 128! Improving the architecture means adding more pixel pipelines (not always useful, if the developer can't use that many pipelines) or upping the clock-speed. Most operations in a modern GPU already take one cycle, so it's not like they're just pushing along inefficient architectures.
New hardware mentioned on Slashdot. Now it's time for all the lamers to come up with the following posts:
1) Who needs all that power anyway? I'm running Windows XP just fine here on my 486SX/33!
2) Why cares if it's fast? It uses up too much power and has a *fan* on it. God forbid a computer have a fan on it! It sucks because it's not fan-less like my Mac!
3) Sure it might be fast, but I bet it isn't as *efficient* as a G4!
4) NVIDIA sucks because it's drivers are closed source.
Did I forget anything? Anyway, I couldn't care less what the lamers think. This is a genuinely cool piece of hardware. There are a few things that make it so:
1) 500 MHz! That's half a gigahertz! A very large jump in clock-speed here, much more so than the usual 33 MHz pussy-footing the industry (particularly Intel!) is guilty of.
2) Compressed-memory access. Ah, computational power exceeds memory bandwidth to the point that it's more efficient just to compress the data before sending it over the bus... The 16 GB/sec memory bandwidth (which is also quite a big jump from existing machines) is made even more impressive by a lossless compression that can achieve 4:1 ratios. This is very helpful for multisample AA graphics, because it reduces the memory bandwidth hit to just the pixels that occupy the edges of polygons rather than every pixel in the scene.
3) Fully floating point pixel pipelines. Carmack was asking for 64-bit floating-point point pipelines a while ago. While this doesn't quite get there (it's 32-bit floating point) it is a major step, and makes life a lot easier for game developers.
Overall, this card is definately in the cards for me:) Maybe along with a dual Opteron machine. And before you scream excess, have you checked Pricewatch lateley? I remember paying $3300 for a single processor PII-300 with 64MB of RAM and a Riva 128 in January of 1998. If the Opterons don't cost that much more than the high-end Athlons today, I could put together this machine for significantly less than that!
Do you think the industry is going to let Microsoft lock in OpenGL 2.0? Sun and SGI depend on OpenGL for their visualization business. Linux is becoming more popular with graphics shops every day. I doubt even Microsoft can go against that kind of industry opposition. Microsoft has a lot of money, but if you attack something like OpenGL, which is central to the businesses of a whole lot of companies, then the money on the other side because rather significant.
Re:Real gamers use Win32, not linux
on
Mesa 5.0 Released
·
· Score: 2
Who cares about games? Soon, we'll be using OpenGL to draw our desktops. Just check out evas_test (from E17) and let your jaw drop. MacOS X ain't got nothing on EVAS! At that point, OpenGL becomes a whole lot more important.
No, that's not right. Mesa is a software implementation, and a piece of support code for the DRI driver. In a hardware accelerated implementation, you've got a device-specific kernel driver, a device specific OpenGL library, and a device-specific GLX driver.
Re:How does it compare on windows?
on
Mesa 5.0 Released
·
· Score: 2
There is no such choice. If you support only OpenGL or Direct3D, you're screwed. If people can't play Quake-engine games, they won't buy your card. OpenGL is basically required support these days.
Re:I don't know what they did - NVidia ?
on
Mesa 5.0 Released
·
· Score: 2
The NVIDIA drivers accelerate OpenGL on NVIDIA hardware. Mesa, unless it has a mini-driver for your card, is a software implementation of OpenGL. There is no Mesa driver for NVIDIA cards, so the NVIDIA driver is still preferred.
They don't have the kind of memory bandwidth these systems need. With AltiVec, a G4 can indeed get a huge gigaflop number, but SIMD floating point takes up a lot of data (with 128 bit SIMD, 20 bytes per 4 operations) and the G4's memory bus runs at a paltry 1.3 GB/sec (compared to 4.2 GB/sec for a P4). Feeding the G4's AltiVec units at full speed requires 20 GB/sec of bandwidth, so once your dataset falls out of the 256K of L2 cache (which these scientific computing applications surely do) the G4 chokes. Besides, AltiIVec doesn't do double precision floating point, whic is necessary for this sort of thing.
To Consistency: The only reason Windows and MacOS are consistent are because one company controls development of the core system. There is nothing technical in the system that encourages consistency. It's like C vs C++. C enables safe code to be written, but C++ gives you tools to enforce that certain conventions be followed. Current thinking in computer science is leaning towards the idea that assumptions should be enforced at the system level rather than at the developer level. This is especially true with distributed development ala open source. And while putting the toolkit in the server doesn't ensure consistency (only HIG guidelines do that, and ideally, all presentation would be left to the system, which could physically enforce the HIGs) it does ensure interoperation. That's one reason why all the toolkits on windows works. They all call into the Win32 layer for high level services like clipboard and printing.
To Performance: It goes beyond the communications bottleneck. The more code there is in the application, the lower the quality of that code is going to be. According to the X mailing lists, this is the real reason people think X is slow. Applications just aren't written for high-performance drawing. By putting the widget set in the server (and ideally, the entire presentation layer) you can have one well-optimized set of code, so applications can be implemented in a straightforward manner and still have high performance.
You've got it backwards:) AWT is a single thin layer on top of many standard services. My scheme is many thin layers on top of one standard service. This isn't something for portability (there would only be one GUI server in this picture), but something for consistency. You have a GUI server that implements a standard set of services. Then, the toolkits become thin wrappers on top of those standard services.
The nice thing about putting widgets server side is consistency and performance.
1) Consistency, because all clients use whatever widget set the server does. By making the server modular, you can use FLTK for handhelds and GTK+ for desktops, and all apps will obey that decision.
2) Performance, because by interfacing clients and the server at a high level, you reduce communication between the two by a huge amount.
The one thing I'd like to see is a set standard GUI services on top of the core drawing engine. Different widget toolkits would be a thin wrapper on top of these standard services, and different widget toolkits would exist to customize the standard services to each language and development model. This way developers could code to whatever API they enjoy (Qt'ish, GTK+'ish, etc) but since these APIs would map to a common set of services, applications would interoperate perfectly. In fact, with would then be easier to write wrappers for "legacy" apps that use straight GTK+ or Qt.
Re:This is This is the exact opposite of my findin
on
New Linux 2.5 Benchmarks
·
· Score: 4, Informative
The instructions involved in the context switch are slow on the Pentium 4. The P4 has a long internal pipeline to flush, and a huge amount of internal state to synchronize, which makes context switches slow. For example, an interrupt/return pair take 2000 clock cycles on the P4!
Slashdot Mirror
I'm interested, what chipset are you running it on? I've used NVIDIA's Linux drivers on the following configurations:
:). I've also had a Duron 750 running the GeForce2 MX and the Athlon XP running a GeForce4 Ti 4200 under Windows, and neither of those machines crash either, even under heavy gaming. I heard that the NVIDIA drivers don't get along well with VIA chipsets, though, and some configs require manual tweeking of AGP settings.
1) PII-300 Intel 440LX chipset - RivaTNT and GeForce2 MX.
2) Athlon XP 1700 + SiS 735 chipset - RivaTNT and GeForce2 MX.
3) Pentium 4 2000 + Intel 845M chipset - GeForce4 Go 440.
I've never had a crash on any of those machines that wasn't my fault (devel software
Nonsense. Even compiling simple C++ heavily templated C++ software takes ages. Hell, even non templated software like KDE takes close to a day. G++ is just plain slow, there is no doubt about it. Of course, C++ is one best of a language to compile, so you can blame G++ entirely. That said, C++'s complexity at the developer end (especially with templates) can pay off a huge amount at the user end. Templates allow you to do "pretty" designs without sacrificing performance. It's a win-win for everybody but the compiler-writers.
The difference is that latency isn't as a big an issue in graphics. In regular code, there are lots of branches and whatnot that depend on the results of a memory access. In graphics (particularly with the frame-buffer) data is moved around in far larger chunks (for example, you'd bring in a large part of a texture at once, rather than just one or two words) so latency doesn't hurt as much. Also, I don't know if latency would be hurt very much anyway. The data is only compressed going over the bus. It's stored uncompressed at either side.
Actually, I don't play games. I do 3D work, scientific programming, and C++ development. However, that stuff requires just as much horsepower as gaming. But thanks for playing, anyway :)
A GeForce4 MX 440 will play older games *really* fast, and runs about $50 (including shipping) on pricewatch. It's got TV-Out too!
It's Dx8'ish (even though it uses OpenGL) in that it uses features specified in the DX8 shader APIs. This means integer pixel pipelines, and small shader programs without loops or other flow control. This card offers full floating-point pixel pipelines, and support for complex shader programs with branches and whatnot. These features are requirements for being fully DX9 compatible.
It should take up the opening next to the AGP slot, as well as the opening for the PCI slot right under it.
As desktops shift to using the 3D engine for 2D, this problem will go away. I tried the EVAS demo the other day, and it blew me away. This *is* the future.
I doubt you know enough about GPU architecture to make that sort of bullshit comment. Graphics is a very simple, very parallizable system, when you get down to it. What matters, (assuming good drivers and adequate memory bandwidth, which isn't always the case) is clock_speed * pixel-pipelines. This has been the case since the Riva 128! Improving the architecture means adding more pixel pipelines (not always useful, if the developer can't use that many pipelines) or upping the clock-speed. Most operations in a modern GPU already take one cycle, so it's not like they're just pushing along inefficient architectures.
New hardware mentioned on Slashdot. Now it's time for all the lamers to come up with the following posts:
:) Maybe along with a dual Opteron machine. And before you scream excess, have you checked Pricewatch lateley? I remember paying $3300 for a single processor PII-300 with 64MB of RAM and a Riva 128 in January of 1998. If the Opterons don't cost that much more than the high-end Athlons today, I could put together this machine for significantly less than that!
1) Who needs all that power anyway? I'm running Windows XP just fine here on my 486SX/33!
2) Why cares if it's fast? It uses up too much power and has a *fan* on it. God forbid a computer have a fan on it! It sucks because it's not fan-less like my Mac!
3) Sure it might be fast, but I bet it isn't as *efficient* as a G4!
4) NVIDIA sucks because it's drivers are closed source.
Did I forget anything? Anyway, I couldn't care less what the lamers think. This is a genuinely cool piece of hardware. There are a few things that make it so:
1) 500 MHz! That's half a gigahertz! A very large jump in clock-speed here, much more so than the usual 33 MHz pussy-footing the industry (particularly Intel!) is guilty of.
2) Compressed-memory access. Ah, computational power exceeds memory bandwidth to the point that it's more efficient just to compress the data before sending it over the bus... The 16 GB/sec memory bandwidth (which is also quite a big jump from existing machines) is made even more impressive by a lossless compression that can achieve 4:1 ratios. This is very helpful for multisample AA graphics, because it reduces the memory bandwidth hit to just the pixels that occupy the edges of polygons rather than every pixel in the scene.
3) Fully floating point pixel pipelines. Carmack was asking for 64-bit floating-point point pipelines a while ago. While this doesn't quite get there (it's 32-bit floating point) it is a major step, and makes life a lot easier for game developers.
Overall, this card is definately in the cards for me
Do you think the industry is going to let Microsoft lock in OpenGL 2.0? Sun and SGI depend on OpenGL for their visualization business. Linux is becoming more popular with graphics shops every day. I doubt even Microsoft can go against that kind of industry opposition. Microsoft has a lot of money, but if you attack something like OpenGL, which is central to the businesses of a whole lot of companies, then the money on the other side because rather significant.
Who cares about games? Soon, we'll be using OpenGL to draw our desktops. Just check out evas_test (from E17) and let your jaw drop. MacOS X ain't got nothing on EVAS! At that point, OpenGL becomes a whole lot more important.
No, that's not right. Mesa is a software implementation, and a piece of support code for the DRI driver. In a hardware accelerated implementation, you've got a device-specific kernel driver, a device specific OpenGL library, and a device-specific GLX driver.
There is no such choice. If you support only OpenGL or Direct3D, you're screwed. If people can't play Quake-engine games, they won't buy your card. OpenGL is basically required support these days.
The NVIDIA drivers accelerate OpenGL on NVIDIA hardware. Mesa, unless it has a mini-driver for your card, is a software implementation of OpenGL. There is no Mesa driver for NVIDIA cards, so the NVIDIA driver is still preferred.
They don't have the kind of memory bandwidth these systems need. With AltiVec, a G4 can indeed get a huge gigaflop number, but SIMD floating point takes up a lot of data (with 128 bit SIMD, 20 bytes per 4 operations) and the G4's memory bus runs at a paltry 1.3 GB/sec (compared to 4.2 GB/sec for a P4). Feeding the G4's AltiVec units at full speed requires 20 GB/sec of bandwidth, so once your dataset falls out of the 256K of L2 cache (which these scientific computing applications surely do) the G4 chokes. Besides, AltiIVec doesn't do double precision floating point, whic is necessary for this sort of thing.
X is a drawing and windowing engine. It doesn't do other GUI-level services like printing, clipboard, etc.
To Consistency:
The only reason Windows and MacOS are consistent are because one company controls development of the core system. There is nothing technical in the system that encourages consistency. It's like C vs C++. C enables safe code to be written, but C++ gives you tools to enforce that certain conventions be followed. Current thinking in computer science is leaning towards the idea that assumptions should be enforced at the system level rather than at the developer level. This is especially true with distributed development ala open source. And while putting the toolkit in the server doesn't ensure consistency (only HIG guidelines do that, and ideally, all presentation would be left to the system, which could physically enforce the HIGs) it does ensure interoperation. That's one reason why all the toolkits on windows works. They all call into the Win32 layer for high level services like clipboard and printing.
To Performance:
It goes beyond the communications bottleneck. The more code there is in the application, the lower the quality of that code is going to be. According to the X mailing lists, this is the real reason people think X is slow. Applications just aren't written for high-performance drawing. By putting the widget set in the server (and ideally, the entire presentation layer) you can have one well-optimized set of code, so applications can be implemented in a straightforward manner and still have high performance.
You've got it backwards :) AWT is a single thin layer on top of many standard services. My scheme is many thin layers on top of one standard service. This isn't something for portability (there would only be one GUI server in this picture), but something for consistency. You have a GUI server that implements a standard set of services. Then, the toolkits become thin wrappers on top of those standard services.
The nice thing about putting widgets server side is consistency and performance.
1) Consistency, because all clients use whatever widget set the server does. By making the server modular, you can use FLTK for handhelds and GTK+ for desktops, and all apps will obey that decision.
2) Performance, because by interfacing clients and the server at a high level, you reduce communication between the two by a huge amount.
XRandR. Already in CVS, GNOME and KDE both of support for it. Next?
The one thing I'd like to see is a set standard GUI services on top of the core drawing engine. Different widget toolkits would be a thin wrapper on top of these standard services, and different widget toolkits would exist to customize the standard services to each language and development model. This way developers could code to whatever API they enjoy (Qt'ish, GTK+'ish, etc) but since these APIs would map to a common set of services, applications would interoperate perfectly. In fact, with would then be easier to write wrappers for "legacy" apps that use straight GTK+ or Qt.
The instructions involved in the context switch are slow on the Pentium 4. The P4 has a long internal pipeline to flush, and a huge amount of internal state to synchronize, which makes context switches slow. For example, an interrupt/return pair take 2000 clock cycles on the P4!
You know what they say, a little bit of knowledge can be a dangerous thing!
Amaya, the w3c browser is actually trying to do just that.