Thanks!
high-end graphics engine
Author
Does anyone know of a computer system/graphics card that can process a million polygons and produce DVI output at 1024x1024 pixels at 200Hz frame rate?
Thanks!
Thanks!
The exact answer largely depends on the number of attributes per triangle, the average size of the triangles and your pixel complexity (and a gaziliion other things). 200hz at 1M triangles is 200million triangles/sec, which is easy for any high end card today. The rates for geometry are in the 1+Billion/s range (up to 2+Billion/s if you include Tesselation) on something like a GTX580.
Author
Thanks for your reply, Crowley99! The attributes that will be of main concern are polygon color, material, textures (per pixel processing); may need to update all 1million polygons + several texture images at each frame. Also need to simulate fog, smoke, explosion, dust effects... I have to confirm that such is achievable with the high-end engines, DVI output 1024x1024 at 200Hz frame rate. 
If anyone has experience or know a system that can handle these requirements, please let me know. Thanks!
If anyone has experience or know a system that can handle these requirements, please let me know. Thanks!
While it is certainly possible, you need to also consider how you manage all of these particles, objects, etc.
You will need to sort by shaders, textures, and depth from view. You will need a fast way to update particles (on the GPU is one way) and cull objects from view (unless this is for a very specific purpose).
If the objects all use the same attributes you don’t need to do much shader swapping.
Your CPU will have some work to do as well.
However my old engine gave me 240,000,000 triangles per second and it was using the slower fixed-function pipeline and a CPU and GPU that are 2 years old.
With newer cards (many of which are over twice as fast as mine) and using shaders efficiently, there is no reason not to expect that you will be able to get far more than 200,000,000 triangles per second, especially on such a low resolution.
L. Spiro
You will need to sort by shaders, textures, and depth from view. You will need a fast way to update particles (on the GPU is one way) and cull objects from view (unless this is for a very specific purpose).
If the objects all use the same attributes you don’t need to do much shader swapping.
Your CPU will have some work to do as well.
However my old engine gave me 240,000,000 triangles per second and it was using the slower fixed-function pipeline and a CPU and GPU that are 2 years old.
With newer cards (many of which are over twice as fast as mine) and using shaders efficiently, there is no reason not to expect that you will be able to get far more than 200,000,000 triangles per second, especially on such a low resolution.
L. Spiro
500 000 vertices * (12byte pos + 4byte uv + 4byte packed normal + 4 byte packed tangent + 4 byte material data (assuming nothing to fancy here) + 4 for for "mystery attribute" ) = ~16 MB/frame
Assuming triangle:vertex ratio is on average is 2:1, 16MB/frame is what is neede for 1m triangles.
=> 200*16 = ~3GB/s bandwidth. This is roughly 1/2 of what PCIE Gen2 is capable of, bit this is still a bit on the high side - even though the theory pans out, pulling geometry from system memory doesn't always reach peak performance (not to mention that things like particules, dynamic textures, etc. may also be pulled from system memory, and may be impacted similarly).
My suggestion would be to keep the raw data on the GPU and use shaders to modify them from a base representation at run-time or incrementally via stream out or UAVs.
Assuming triangle:vertex ratio is on average is 2:1, 16MB/frame is what is neede for 1m triangles.
=> 200*16 = ~3GB/s bandwidth. This is roughly 1/2 of what PCIE Gen2 is capable of, bit this is still a bit on the high side - even though the theory pans out, pulling geometry from system memory doesn't always reach peak performance (not to mention that things like particules, dynamic textures, etc. may also be pulled from system memory, and may be impacted similarly).
My suggestion would be to keep the raw data on the GPU and use shaders to modify them from a base representation at run-time or incrementally via stream out or UAVs.
I would like to add a simple opinion.
Why would you like 200Mhz frame rate? 30 frames / sec needed for smooth "movement". That is about 30 Mhz. LCD monitors usually use 75Mhz, they will never run on 200Mhz, even if your program say so (37.5% of the frames will be displayed).
Why would you like 200Mhz frame rate? 30 frames / sec needed for smooth "movement". That is about 30 Mhz. LCD monitors usually use 75Mhz, they will never run on 200Mhz, even if your program say so (37.5% of the frames will be displayed).
i think you mean "hz" not "Mhz." There is no GPU that i know of that runs frames on the "Mhz" level. You're talking about 30,000,000 frames per second. Which is MUCH more than 30 frames per second. (hz means "cycles per second")
I'm assuming that LCD's are refreshing at an interval of 60hz in the United states. Besides the whole mega, not mega thing, your post is very accurate.
I'm assuming that LCD's are refreshing at an interval of 60hz in the United states. Besides the whole mega, not mega thing, your post is very accurate.
DVI output at 1024x1024 pixels at 200Hz frame rate?
1024x1024 pixel at 32bit at 200Hz are about 6.7GBit/s, DVI is specified for 4.9GBit/s.
You might be not able to push that, I suggets you'll use dual-dvi oder hdmi to overcome that limit.
1Mio tri/frame actually means you have mostly 1pixel sized triangles, is that really needed? there are usually other ways to get this detail without a noticeable quality loss.
In my experience, going over 120-140 hz is going to be really hard no matter what. Drivers appear to be just throttling down after a certain point. I'd consider to review this requirement.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
