n00b question regarding polygon count

[Ken2012]

Hello all, I'm new here

OK, after trying to find the straight-up answer to this all over the place, my question is: Is raw poly count a CPU or GPU intensive task, spefically in games?

I've always been lead to believe that recent GPU's, with their vertex pipelines (that is, they porcess x number of vertices per clock), offload the actual 'wireframe' of a 3D environment, both the geometry of the world (BSP or otherwise) and any externally-created models, from the CPU. Although recently it's come to my attention that it's actually the CPU that 'looks up' all the vertices (that is, keeps track of everything's 'physical' location in the environment), while the GPU takes this information and applys texturing/shading, mip-mapping, lighting etc.

Thanks.

 

[bloodbob]

Both generally.

The vertex has to be created on the CPU well thats pretty much true. In the future some of the vertexs will be generated on the CPU and on the GPU ( yes I know the X1K has supposedly launched but there ain't many ).

Once it hits the GPU it has to do the fixed function operations such as transformation and lighting. If the developers has coded a vertex shaders thats where vertex power really comes into play.

 

[JHoxley]

You've got bits-n-pieces correct

In a sense we do upload all of the data to the GPU. It's pretty much performance suicide to try and render from SYSMEM however, it is common for the CPU to have a copy of some (if not all) of the geometry data for it to work on (e.g. animation, physics, culling, LOD etc..)

Where the CPU gets involved in the mix is that it still issues the commands to draw stuff. Even though the shaders, geometry and textures are all located on the GPU it's still the CPU that effectively says "take x,y and z now go render them".

The term "CPU Bound" refers to the situation when the GPU is operating faster than the CPU. The CPU says "Go render x,y,z" and the GPU does, and unless the CPU is ready to issue another command "Go render a,b,c" then the GPU will sit there killing time waiting for that instruction. All the time that it's waiting is wasted time.

The flipside of that is if the CPU delivers too much data and the GPU is working flat-out 100% yet still doesn't get the job finished by the time the CPU wants to offload more instructions it'll be the CPU that's waiting. Imagine the CPU shouting "are you ready yet?" at the GPU

The ideal situation is one where the CPU can offload it's work onto the GPU's queue and return immediately (implying the GPU's queue is *not* full) and that the GPU's queue always contains *something* (it's never waiting for new instructions). Trying to get that balance is no easy thing!

In DX10 the predicated rendering, stream output and GS will, just for fun, make it just that bit more complex/powerful.

hth
Jack

 

[Ken2012]

OK thanks guys, but I have another little follow-up query: Just how much is the GPU responsible for physics? Some people seem to think that the upcoming PPU (PCI cards) will invariably kill off the current crop of multi-GPU/video card configuartions that are SLI and Crossfire, simply due to the fact that since all the physics calculations that the GPU (and CPU) currently have to handle are/will be offloaded onto a dedicated physics processor, effectively leaving much of the (physics-processing) GPU power 'going to waste'. Do you guys think it will turn out this way, or is this nothing but bs?

 

[pc999]

Good read.

http://www.beyond3d.com/forum/showthread.php?t=25005

 

[Crusher]

GPUs are rarely used for anything but rendering right now, so transferring physics from the CPU to a dedicated PPU wouldn't relieve the graphics cards much at all. GPUs mainly just handle creating the image of the scene once all of the positions and effects have been determined... it's the CPU's job (or possibly in the future CPU and PPU together) to calculate the position of everything before it's drawn.

 

[Subtlesnake]

I'd like to pop in with a question. Is the physics side of something like deformable cloth handled by the CPU, or the vertex shaders or both?

 

[Crusher]

Realistic cloth can be done with either CPU or vertex shaders. Same goes for other mesh deformation models (water surface, for example), and things like volumetric shadow generation. Those are the kinds of special case things that can be balanced between the CPU and GPU based on the demands of the application and even the current hardware configuration of the computer running the program. My guess would be that most people just do it all on the CPU for simplicity and due to the fact that the majority of computers have much better processors than they do video cards, but I don't know for certain (and the console arena may be very different).

 

[Mat3]

I always thought the video card's memory held textures and static geometry (space permitting), but dynamic geometry stayed in system RAM so it could get processed by the CPU, then it would be sent to the GPU for transformation (assume hardwired T&L). Is that close, or how exactly does that work?

 

[Reverend]

The perfect Rev would be a remote with more buttons (2)(and the rest of the controler of curse), standard microphone, a second remote by Rev.

For the last time -- I am not a machine.

 

[Humus]

I always thought the video card's memory held textures and static geometry (space permitting), but dynamic geometry stayed in system RAM so it could get processed by the CPU, then it would be sent to the GPU for transformation (assume hardwired T&L). Is that close, or how exactly does that work?

It can be done either way. Keeping things in AGP memory allows for fast write access, but is on the other hand slower to read from the GPU. If you update something dynamically and only use it once, then this could be faster. If you update a dynamic buffer, but use it numerous times between each update, it may be faster to keep it in video memory. If you have a static mesh, it will be fastest to keep it into local video memory, but even in this case, there are still cases where it's faster to keep it in AGP memory (for instance if you're low on video memory for other stuff like textures).

 

[pc999]

For the last time -- I am not a machine.

I am not sure why you put this here , but anyway you dont need tu use it all in the same game/time...
1-buttons are always good for more stuff
2- micro is good to reduce the need for buttons (those for reload, itens selection...), or very complex comands (RTS;tatical FPS to say Team A go point 3, in formation X;provid cover to team B.Team B go to...or like UT see the links, would be a nightmare without one).
3-for boxing, sword and shield etc...

I am not a machine too, but I like to have a lot of options to a lot of differents games (althought 1 and 2 (specialy 2) are a good possibility, I hope , I dont have many hopes in the rest ).

 

[Reverend]

Rotfl !!!!

 

[Crusher]

pc999, I have no freaking idea what you're talking about, but it's quite obvious you missed the point.

 

[pc999]

As my post show, I compeletely belive in both of you, fell free to explain me (please), as I have no clue why Reverend had quote my sig and made that coment (or at least why here? ?).

 

[Geo]

You guys will be pulling the wings off butterflies, next.

"Rev" (check your sig) is the generally accepted shortening of "Reverend". In other words, "The perfect Reverend would be a remote with more buttons. . ."

 

[pc999]

I need a giant

Anyway this is the colateral damage of discution to much the mouse like possibilitys of the Revolution.

Sorry again, sig clarified.