• Advertisement
Sign in to follow this  

idea for gpu physics implementation

This topic is 3029 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi one problem with doing physics on the gpu (with hlsl) is reading the results back to the cpu efficiently I am using a single swapchain with 3 backbuffers and rendering some physics calculations into a texture whilst also rendering to the backbuffer Is it the case that once my backbuffer has been swapped to the frontbuffer (after 3 present()s) that I can consider all my textures fully resolved and ready for reading back? In which case I need to wait (number of backbuffers in the swapchain) frames before reading back to avoid stalls etc. In my application I am limited to a single swapchain and was considering a technique to ensure I get the physics data back efficiently before each frame update as follows: start: render physics to textureP render game to textureG render textureG to backbuffer present() render textureG to backbuffer present() render textureG to backbuffer present() read physics from textureP do something with it goto start and maybe flipflopping between two textures to give gpu room to breath I hope somebody can confirm this approach is sensible Thanks

Share this post


Link to post
Share on other sites
Advertisement
Sounds like a bad approach. For example, if the user is running your app with vsync on at 60Hz, you're getting a maximum 20fps.

The best thing to do is try to separate physics processing from graphics processing. You don't want them synced unless your physics can be read directly by the graphics pipeline, with no CPU intervention. Use an event query to discover when your physics processing has finished, then read the result and do what you need with it.

Share this post


Link to post
Share on other sites
hi

thanks for your reply

because I am targetting xbox with xna:
- I have control over vsync
- But no control over the swapchain / present

I do have occlusion query available which I could use to detect when physics results are available

But getting the results early won't help me

It is better to get them predictably "late"

by increasing the frame rate and only rendering the game once every N frames
I think I can achieve my goal - to get results of gpu calculations without pipeline stalls and always before the next frame is (re-)rendered

Share this post


Link to post
Share on other sites
But you then miss the point: the entire idea is that you're getting a performance speedup from using the GPU. Quite frankly, I can't understand why anyone would intentionally use a method that will cause a (quite large) performance drop for zero quality increase, especially when there's nothing preventing you from making a reasonably fast CPU implementation.

Share this post


Link to post
Share on other sites
Quote:
Original post by InvalidPointer
But you then miss the point: the entire idea is that you're getting a performance speedup from using the GPU. Quite frankly, I can't understand why anyone would intentionally use a method that will cause a (quite large) performance drop for zero quality increase, especially when there's nothing preventing you from making a reasonably fast CPU implementation.


That is a good point

but as I am targetting xbox360 using xna you can't do anything reasonably fast on the CPU - for some things pushing it to the GPU is your only choice

For instance I have a broad phase collision detection system written in HLSL that can handle 10,000 objects colliding with each other at about 20 fps that would take a few minutes to run on the CPU ...

Another case is a large scale terrain renderer which is 99% GPU based but the only way I can get height data back to the CPU is with a readback (not enough memory left to read the same textures in twice)

I did a test implementation spreading the workload across 3 frames and I get 150 fps with a scene update every 3 frames = 50 fps

(For my purposes as long as I can stay >= 25 fps I am happy)

So it looks like a feasible way get data back from the GPU on XNA

Whether that works in reality though ...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement