Jump to content
  • Advertisement
Sign in to follow this  
vlj

What happens if gpu reads and cpu write simultaneously the same data ?

This topic is 838 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

AMD is actively marketing LiquidVR and I'm wondering how they could implement the "latest data lane" tech and if it could be reproduced outside of VR.

As far as I understand Latest Data Lane is basically letting the gpu fetch VR heaset tracking data instead of filling a buffer cpu-side. This way the view matrix is using information available at gpu render time instead of relying on data that were recorded sometimes 2 frame before.

 

I don't know the detail however I'm suspecting headset driver is polling location at a high frequency rate and write them to some gpu visible memory. It's highly likely that concurrent read/write happens in such memory location so I'm wondering what is the actual memory behavior in such case.

If a (uncached) memory adress initially hold N bytes of data (with N being the biggest size of memory handled by load/store operation on the cpu arch) a0 a1 a2... aN and a thread is storing data b0 b1 b2... bN while gpu is reading data for a buffer copy operation, what will the gpu "see" ? Does it see either a0 a1 a2...aN or b0 b1 b2.. bN, or does it see a mix of bytes from a and b ? Or does it see garbage value (ie memory is in undefined state between the moment the store operation starts and the moment it finishes) ? 

Share this post


Link to post
Share on other sites
Advertisement

I found the documentation on it: https://github.com/GPUOpen-LibrariesAndSDKs/LiquidVR/raw/master/doc/LiquidVR.pdf

It's actually being called Late Data Latch and the whitepaper has a brief explanation:

 

The Late Data Latch helps applications deal with this problem by continuously storing frequently updated data, such as, real-time head position and orientation matrices, in a fixed-sized constant buffer, organized as a ring buffer. Each new snapshot of data is stored in its own consecutive data slot. The data ring buffer has to be large enough to ensure the buffer will not be overrun and latched data instance will not be overwritten during the time it could be referenced by the GPU. For example, if data is updated every 2ms, a game rendering at 100fps should have more than 50 data slots in the data ring buffer. It is advised to have at least twice the minimum number of slots to avoid data corruption. Just before the data is to be consumed by the GPU, the index to the most up-to-date snapshot of data is latched. The shader could then index into the constant buffer containing the data to find the most recent matrices for rendering.

Edited by Promit

Share this post


Link to post
Share on other sites
one processor increments the counter after it is done writing data to the buffer the counter will point to.
the other processor is reading the counter before reading data from the buffer. Edited by Krypt0n

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!