4
\$\begingroup\$

I'm wondering about gpu accelarated physics after reading about Erwin Coumans presentation on GPU accelerated physics: http://www.gdcvault.com/play/1018185/GPU-Rigid-Body-Rigid-Body (demo video here: http://www.youtube.com/watch?v=ZkF4yMmP0R8)

While it certainly looks like a massive performance boost, I don't have any expirience with gpgpu programming, so I'm wondering how practical this is for games. You'd have to manage communication between the different parts of the game engine. I know there are facilities to have opencl & opengl share memory, that covers the rendering part.. but what about the other parts of a typical game engine? Let's say we have a fixed timestep physics simulation (lets say 60hz) and corresponding game logic (which also runs at 60hz) that needs to act on certain events triggered by the physics engine. Game logic is not necesarily suited for execution on the gpu, it may for example be very branching intensive. This would mean a readback from the gpu to the cpu, wouldn't this create too much latency to have our game logic proceed at 60hz?

\$\endgroup\$
2
  • 4
    \$\begingroup\$ The answer to your question is yes. What those nice and nifty GPGPU papers that claim (and actually do manage to do it) to accelerate the physics simulation do not tell you is how they envision the transmission of collision callback to other parts of the engine (particularly the AI is one of the most concerned modules). Of course, at least on the PC, you must read back some data from the GPU (transformation/pose matrices for sure, collision data, etc.). Aside from special cases (particles, cloth, springs, stacks of rigid bodies from explosions), tasks are not trivially paralellizable. \$\endgroup\$
    – teodron
    Commented Aug 14, 2013 at 15:13
  • \$\begingroup\$ That's what I'm afraid of, I found two references which both seem to support this story: developer.nvidia.com/content/… and gamedev.stackexchange.com/questions/51309/… Still some links in the discussion below Jovan's answer seems to show some promise. I guess we have to wait and see what the author of bullet physics comes up with.. \$\endgroup\$
    – Martijnh
    Commented Aug 14, 2013 at 20:15

1 Answer 1

Reset to default
4
\$\begingroup\$

You'd have to manage communication between the different parts of the game engine.

You have to do this anyway though.

I know there are facilities to have opencl & opengl share memory, that covers the rendering part.. but what about the other parts of a typical game engine?

GPGPU and the Rendering Pipeline are independent. The Rendering Pipeline is a special-purpose operation. You can run GPGPU instructions by themselves without submitting anything to be rendered.

Let's say we have a fixed timestep physics simulation (lets say 60hz) and corresponding game logic (which also runs at 60hz)

Is this a realistic scenario at this point? Will you actually have physics and game logic executing the entirety of their updates that often?

A renderer being able to draw at 60 frames per second is one thing. But processing physics, game logic (including AI?) at that rate is something else entirely.

Game logic is not necesarily suited for execution on the gpu, it may for example be very branching intensive.

Pre-emptively remove branches where and when it makes sense to do so. Use threads with mark and sweep and rework your data so it doesn't need to branch.

This would mean a readback from the gpu to the cpu, wouldn't this create too much latency to have our game logic proceed at 60hz?

So this is the major question. It's also somewhat loaded.

GPU can execute a lot more code in parallel than your CPU can, which means that if you have a lot of data to process - enough to dwarf the latency of transferring data between CPU and GPU - then you might benefit from this.

The presentation you linked deals with A LOT of data, performing an SIMD operation. They are bound to see a performance increase. As teodron also commented, they use tasks that naturally lend themselves to parallel execution and SIMD operations.

\$\endgroup\$
10
  • \$\begingroup\$ I understand there's a turning point, if simulating 1 million objects on the gpu take 0.01 sec + 0.1 sec synchronization latency vs 1 second sim time on the cpu thats a clear win.. but still not practical for a game where we need to simulate faster than 10hz).. so what latency can we expect on a moderatly modern pc architecture? \$\endgroup\$
    – Martijnh
    Commented Aug 14, 2013 at 19:02
  • 1
    \$\begingroup\$ @Martijnh - The PCI Express bus is one of the major influences in the latency: idi.ntnu.no/~elster/master-studs/runejoho/… \$\endgroup\$
    – Jovan
    Commented Aug 14, 2013 at 19:05
  • \$\begingroup\$ @Martijnh when you say latency, are you referring to the time it takes to copy your data to and from the GPU? \$\endgroup\$
    – alrikai
    Commented Aug 14, 2013 at 19:05
  • 1
    \$\begingroup\$ @Martijnh Right, then the answer is that it depends. You'll have an upper threashold based on your PCIe speed, but in reality you'll never reach the max PCIe throughput anyways. You can amortize the latency using streams (depending on your application). But really, the GPU is best suited for large data transfers and batch processing, not many small transfers \$\endgroup\$
    – alrikai
    Commented Aug 14, 2013 at 19:13
  • 1
    \$\begingroup\$ @Martijnh Many times for small transfers you'll find it's faster to just process it on the CPU. Plus implementing things on the GPU will take much longer, especially if you want it to run efficiently. But really it depends on the application, I'd say go the CPU route, and if you find the physics to be a performance bottleneck, only then try the GPU route. \$\endgroup\$
    – alrikai
    Commented Aug 14, 2013 at 19:27

You must log in to answer this question.

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