CPU and GPU cooperation
Author
How well do the CPU and GPU play together? If the GPU has not finished rendering a scene by the time the CPU finishes it's iteration of the game loop, does the CPU wait for it to finish? Would it be more efficient to call the render function first, that way it is likely to finish rendering before the CPU finishes with its work?
How would the GPU even know whether the CPU is at the end of the 'loop'? It doesn't - all it cares about is the data you send it. Nor is the CPU at the 'end of its work' just because it happens to be approaching the end of a loop in your high level language - the loop just repeats and the work begins again!
There are some micro-optimisations you can perform regarding the way you send that data but chances are high that you don't need to worry about that whatsoever. Just update, render, repeat.
There are some micro-optimisations you can perform regarding the way you send that data but chances are high that you don't need to worry about that whatsoever. Just update, render, repeat.
Author
I see, that makes sense. Couldn't there be some weird results if say, the CPU were to get way ahead of the GPU in its work? Maybe I'm thinking about this the wrong way.
So now the CPU would be 3 game frames ahead of the scene that is being rendered. Or would something happen like each frame that the CPU calls the render funtion, the GPU would stop what it was doing and begin again with the data sent to it? Would an incomplete scene be rendered if this was the case? Or are GPU's so fast in their task that this would basicly never happen?
CPU executes instructions | GPU executes instructions \/ | \/ CPU executes instructions | \/ \/ | \/CPU executes instructions | \/ \/ | \/So now the CPU would be 3 game frames ahead of the scene that is being rendered. Or would something happen like each frame that the CPU calls the render funtion, the GPU would stop what it was doing and begin again with the data sent to it? Would an incomplete scene be rendered if this was the case? Or are GPU's so fast in their task that this would basicly never happen?
I think it's a bit more complicated than what people have been saying. This is all from memory, so it may be wrong. With modern graphics cards the gpu is always a frame or two behind the cpu (this allows it to process more in parallel more of the time). But there are some functions which block, and make the cpu wait for the gpu. These are things like swap buffers, or functions that read from video memory. If the gpu is not finished rendering when swap is called, I believe thedriver will block the cpu from doing any more (in that thread). The gpu will wait for the cpu when it finishes rendering if swap has not been called. Even this is probably a simplifcation.
Generally you wouldn't bother updating until the GPU is free to draw the "frame" that you've just prepared on the CPU (i.e. updated objects etc)
so instead of:
You'd have:
And as far as i know the GPU is never "a frame or two behind", largely because the CPU may be altering resources that the CPU is currently trying to render.
Andy
so instead of:
-----------------------------------------------------CPU executes instructions | GPU executes instructions \/ | \/ CPU executes instructions | \/ \/ | \/CPU executes instructions | \/ \/ | \/You'd have:
-----------------------------------------------------CPU executes instructions | GPU executes instructions \/ | \/ CPU waits | \/ \/ | \/CPU waits | \/ \/ | \/And as far as i know the GPU is never "a frame or two behind", largely because the CPU may be altering resources that the CPU is currently trying to render.
Andy
Quote:Original post by CandleJack
Couldn't there be some weird results if say, the CPU were to get way ahead of the GPU in its work?
The two processors work independently, in parallel, as far as they can. However, if the GPU is relatively overloaded, the scenario you described can and often does occur. For this reason, the graphics API sets a limit in the asynchronicity [apparently, it's a word] it will tolerate. I can't speak for OpenGL, but I know Direct3D won't let the CPU get more than two frames ahead of the GPU. It's possible that this sync-management is governed by the driver, and the limit may be altered on the fly, according to the API/driver's heuristics.
When such an overrun occurs, the API won't return from its Present() or equivalent call until the GPU is less than so many frames ahead.
Regards
Admiral
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
