I'm learning OpenGL and today I read something new to me. It's called transform feedback, and if I understand right, it can help to get information about vertex shader variables. And I read an example where a particle system was created, with collisions. After reading it I have a question: Is it sensible to make all physics like this, i.e. is there any kind of profit from this?


1 Answer 1


Physics done on the GPU are usually cosmetic effects. Particles are a good example, but hair and tall grass are similar. The GPU is very good at doing a massive number of calculations and since it also handles the drawing if these things it is a good match.

A GPU isn't very fast at communicating the results back to the CPU. This is why physics used in actual gameplay is done locally on the CPU: Collisions may affect both colliding objects or trigger other gameplay effects (e.g. points scored) so it makes more sense to handle that on the CPU.

Some physics effects may benefit from using the GPU to do some calculation offloading, but those are often handled by a specially designed physics core.

So in general, non-gameplay special effects that require some degree of physics are suited to run on the GPU.

  • \$\begingroup\$ Thank you for answer. But why I should send info back to CPU? Maybe it's dumb question, but I I'll ask. Why I can't allocate some memory from GPU to store data there? \$\endgroup\$ Jul 14, 2016 at 6:36
  • \$\begingroup\$ If your game logic needs the info (for example an enemy is hit by a rock, the game needs to play a soundeffect) meaning the result should be sent back to the game. Now in desktop PC architecture GPU memory is separate from the mainboard memory. In console architecture there is usually some 'shared' memory space both the GPU and the CPU can access and is usually used for this type of communication. However in most situations these memory blocks are not shared. \$\endgroup\$
    – Felsir
    Jul 14, 2016 at 6:43
  • \$\begingroup\$ @АйратНасыров Moving data around between CPU and GPU across system bus is inefficient; when you urgently need that data for other tasks so you can complete a frame of game logic in 1/60 sec, you haven't time to wait for such transfers to occur... generally speaking. Some games will run things 1-2 rendering frames behind the current logic tick, in order to give that data time to propagate back and forth (the same technique is also sometimes used in networking). If a particle has a gameplay effect like burning a character in the current frame, you need it now, not 2 frames from now. \$\endgroup\$
    – Engineer
    Jul 14, 2016 at 8:20
  • \$\begingroup\$ Thank you. Is 2 frames are really so important? I think no-one can feel it) I mean it's 2/60 sec!!! \$\endgroup\$ Jul 14, 2016 at 9:14
  • 1
    \$\begingroup\$ it is a cascading effect. 2 frames before the game can react also means effect resulting from it may have a 2 frame delay and so on. In most games speed is everything; which is also the reason some effects are offloaded to the GPU. \$\endgroup\$
    – Felsir
    Jul 14, 2016 at 9:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .