Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
4  
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. –  teodron Aug 14 '13 at 15:13
    
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.. –  Martijnh Aug 14 '13 at 20:15
add comment

1 Answer 1

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.

share|improve this answer
    
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? –  Martijnh Aug 14 '13 at 19:02
1  
@Martijnh - The PCI Express bus is one of the major influences in the latency: idi.ntnu.no/~elster/master-studs/runejoho/… –  Jovan Aug 14 '13 at 19:05
    
@Martijnh when you say latency, are you referring to the time it takes to copy your data to and from the GPU? –  alrikai Aug 14 '13 at 19:05
1  
@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 –  alrikai Aug 14 '13 at 19:13
1  
@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. –  alrikai Aug 14 '13 at 19:27
show 5 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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