0
\$\begingroup\$

I am trying to make a 3D game with C++, SDL, and OpenGL.

My program roughly looks like this:

enter image description here

control function has only CPU operations.

draw function has CPU and OpenGL functions operations.

I just randomly pick numbers.

How can I use GPU when program at control function?

Or I need to use? Do game engines use at every time? For example Unity, or Unreal Engine.

\$\endgroup\$
  • \$\begingroup\$ So basically you wonder how you could burn your GPU when you don't need to use it? \$\endgroup\$ – Alexandre Vaillancourt Mar 1 at 18:58
  • 1
    \$\begingroup\$ @AlexandreVaillancourt :D. Does gpu need to take a breath ? I want to reduce the total cycle time. \$\endgroup\$ – Emre Kaya Mar 1 at 19:24
  • \$\begingroup\$ How do you know that the GPU is not being used in the control function? Especially when you use OpenGL, there are functions not meant for drawing (for example messing with matrices) that are being calculated on the GPU behind the scenes, at least when available. \$\endgroup\$ – TomTsagk Mar 4 at 12:06
  • \$\begingroup\$ Are you saying this : opengl functions keep going work after program passing it. ? If so , i didn't know this. \$\endgroup\$ – Emre Kaya Mar 5 at 19:23
2
\$\begingroup\$

There are some games which actually use at least two threads - one for rendering and one for gameplay. While the rendering thread renders the current gamestate, the gameplay thread calculates the next.

But this software architecture is a lot more complex than it seems at first glance. If implemented poorly it can actually hurt performance.

One problem is that it is important to synchronize these two threads properly. You don't want the renderer to render half of the previous and half of the next state. Badly implemented thread synchronization can have worse performance than doing the same things in a single thread.

Another is that you need two copies of the gamestate (or at least of those components which are relevant for rendering). One copy for rendering and one copy the gameplay thread builds . And those two copies better don't get out of sync. A naive approach to this is to just create a whole new copy of the gamestate, but that means that you might copy a lot more data each update frame than you need to.

\$\endgroup\$
2
\$\begingroup\$

The classic standard answer for single-threaded games is to render first, then update game logic, and only then call your SwapBuffers.

while (running) {
  draw();
  update_game_logic();
  GL_SwapBuffers();
}

If you render first and then update game logic, the GPU can continue processing the submitted rendering commands while the game logic is updated on the CPU.

It's worth noting that really the important part there is to keep your draw and SwapBuffers calls far apart from each other. For example, if you really want/need to do your game logic in the beginning of the loop, you can actually SwapBuffers before draw (so you're syncing the previous frame before rendering the next frame).

while (running) {
  update_game_logic();
  GL_SwapBuffers();
  draw();
}
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.