Slashdot Mirror
Preview of The GeForce 256
Tor Arne writes " Gamecenter is doing a preview of the Nvidia GeForce 256. Not as amazing as it initially sounded, it's still pretty amazing looking."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
> Hardware T&L greatly increases the amount of onboard memory needed.
.. I dunno, between 64 and 128 bytes (you need your texture indices too, remember)), you're using between one and two GB/s of bus bandwidth if all you're doing is reading each polygon once.
No facts to back this claim up. How exactly does hardware T&L increase the amount of onboard framebuffer required? With AGP, there really is no need for local video memory at all, except to use for the actual visual screen, and maybe as a texture cache. Sure the geometry system will need somewhere to cache scenes, but to fill up 128MB with just _geometry_ information you'll need something as complicated as that huge landscape scene in the Matrix.
Certainly hardware T&L does not increase the size of the framebuffer needed. However, AGP is really not as fast as the RAM they're putting in these systems - hell, all bus issues aside, system RAM is only 100 MHz, while most video cards local memory is way faster, or on a wider bus or both.
When doing the geometry, you don't want to tie up your bus to read and write and read each vertex as you translate and light each frame. Sure, it is possible to do it with AGP, but is it efficient? Let's see, they say it can push 15 million polys a second? Say a poly takes up
If this is 60 fps, each of those frames is 16-32 MB. 128 MB will be more than most applications will need. But using an extra 32 for geometry information is not unwarranted, in their pushing-the-card-to-its-limits case.
Disclaimer: I'm not as smart as I think.
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
--
?
More importantly, a fixation on clock speed is quite silly, as it is merely one of the factors in how fast a system is. I'm rather more impressed if they produce a faster product that doesn't have as fast a clockspeed.
Furthermore, keeping the clock speed down has other merits such as that it likely reduces the need for cooling, as well as diminishing the likelihood of the chips being stressed into generating EMI.
(Entertaining rumor has it that 900MHz systems that are likely coming in the next year may interfere with the 900MHz band used by recent digital cordless phones...)
If you're not part of the solution, you're part of the precipitate.
Actually OpenGL has had support for onboard T&L for quite some time. When these guys are developing these games, you can bet that their rigs have boards with T&L (If they aren't a poor startup).
What will be interesting in the future, will be the test results of the Voodoo4 (or whatever it will be called). This card should be able to do more with a lower framerate due to it's support of motion blur.
If you are talking about T-Buffer technology, you may be grossly overestimating its power. In the demos that I have seen (and granted, these are 3dfx demos and they are nasty, why wouldn't a company trying to sell its product produce decent demos to show it off???, but I digress) all your motion blur will get you is a loss framerate since your CPU has to fill the T-Buffer with x images, which then get blended to produce the effect. While it may look purdy, it is going to require one hell of a CPU to pull it off. I think the fullscene anti-aliasing is going to be the selling point on that board.
I think something that will be interesting to point out is that 3dfx has done a really good job at throwing their marketing prowess at consumers with in respect to the GeForce 256. While I don't quite believe everything that nVidia says, I find it hard not to support them when 3dfx has gone so far out of their way to make nVidia look bad. I will paraquote a developer (can't remember his name):
The "Top 10" Reasons to procrastinate:
10.
Does any one know if the Linux drivers for this thing (which have been promised) will be day and date with the cards themselves?
And when will ID start supporting Q3A on the nVidia cards? I HATE rebooting into Windows!
I want one of these SO BAD, but I'm not going to give up XF86 for it!
-- IANAEG - I am not an elder god.
However, games will need to be specially written to take advantage of this geometry acceleration.
This is only true if you were unfortunate enough to write your game using Direct3D. OpenGL games will be able to take advantage of geometry acceleration without even recompiling. You reap what you sow when you use a Microsoft API.
Whether or not hardware T&L is of any benefit to current or future games is yet to be seen though. Games lately have been getting more and more fillrate bound and less geometry bound, as game creators take advantage of higher resolutions and larger textures.
The GeForce, on the other hand, supports up to
128MB of local graphics memory. Hardware T&L greatly increases the amount of onboard memory needed. The first boards aimed at consumers should come out at 32MB, with 64 MB and 128MB cards to follow later on.
No facts to back this claim up. How exactly does hardware T&L increase the amount of onboard framebuffer required? With AGP, there really is no need for local video memory at all, except to use for the actual visual screen, and maybe as a texture cache. Sure the geometry system will need somewhere to cache scenes, but to fill up 128MB with just _geometry_ information you'll need something as complicated as that huge landscape scene in the Matrix.
Texture compression allows the use of much more detailed textures without overburdening graphics memory or bus bandwidth.
My jury's still out on texture compression. For games that are poorly written (i.e. that load and release textures on the fly, each frame) compression can help, but for games that use a more intellegent caching scheme for texturing, there really isnt much of a point.
Like the TNT2, GeForce supports the AGP 4X standard.
Definitely "A Good Thing".
The GeForce also introduces a new feature, cube environment mapping, that allows for more realistic, real-time reflections in games.
Similar to the Matrox G400's env mapped bump mapping but not quite the same.
Other things to note: 4 texel pipes (fills at four times the clock rate). Watch for all the other chip makers to do this too, limit of 8 lights in hardware (what happens when a scene requires more than eight? They don't say.. hmmm......)
Basically nVidia is gambling with hardware geometry. The gamble is, that future host cpu's (Pentium-4's or whatever) will not be able to beat them in doing transformation and lighting, and that if they don't, gamers are going to really even benefit from T&L. We'll see if that pans out. Unless they have a very sophisticated ALU on that chip, it will doubtlessly only speed up certain types of scenes. (We've all seen the "tree" demo).
You can play Q3A on nVidia. Check out nvidia's linux FAQ. It's got links to the drivers, and instructions for Q2/Q3. Yes, they all say it can't be done, etc etc, but believe me, I run Q3test on a TNT2 all the time, it works fine. It's just not officially supported. Have fun! :-)
----
We all take pink lemonade for granted.
There is no K5 cabal.
I am not the real rusty.
The idea of Hardware T&L and texture compression are nice improvements but as has been repeated many times for many hardware additions (MMX, 3dNow, the new IBM crypo chip) software (read apps) has to be written to take advantage of these new features. I would much rather see a CPU with enough FPU power and cache to handle the software T&L as it exists now in games. If film runs at ~24FPS what makes it look as good as a game running at 40-60fps? In my opinion it comes from the frame rate drops and stutters that occure when rendering scenes or perspective changes. When in Half-Life and I walk out of a hall to an open area my TNT drops from about 20-25 fps to 12-17 fps. Throw in a couple of light sources in any rendering and your slowing the whole thing down more.
Why does this matter you ask, well, your eyes can definately see the frame rate jumping up and down, even if you see no major difference in the smoothness of the animation. I would rather have any type of T&L as well as buss and fill rates that allowed me to push a steady 25-35 FPS in what ever game/app was rendering in the resolution i wanted. If it pushed 70-80 and dropped to 30 on a tough scene it would not matter much as I would cap my frame rate at about 35-40. Then my fps stays a STEADY 25-40 and doesn't drop to an un acceptale rate, also the app code doesnt get bottenecked when the frames push super high. I dont want 300 fps at 1280x1024, i just want ROCK SOLID frames between 25-40 when rendering ANY scene. Of course Having hardware T&L and for pipelines is nice for being able to do more detailed goemetry and faster as long as the software offloads its T&L to the hardware. However I think that we are getting pretty damn close to the maximum detail level thats needed in games. We can use some more but not a whole lot. The most important thing is that we can dot it at a steady rate.
Flame Away!!
www.mp3.com/Undocumented