Jump to content
  • Advertisement
Sign in to follow this  
Nairou

Geometry caching: vertex buffer conflicts?

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

I've been reading discussions here about the rendering process, specifically how to transfer geometry into the vertex buffers that get rendered each frame. I really like Yann's sliding slot method, it answered my questions about vertex buffer fragmentation, but I still have one issue I'd like to get cleared up. Let's say you have your large vertex buffer (VB) which you're using as a cache, and you are adding new blocks of geometry as they become visible and removing blocks of geometry as they are no longer needed. The concept is all well and good, but what about the performance of continually writing to that VB? I'm assuming it is a static VB, in order to keep it in VRAM. We're not rewriting the entire VB every frame, so I'm assuming it isn't a dynamic VB. But if it is static, wouldn't that mean that we'd potentially be locking and writing to the VB at the same time that the GPU is reading from it? Sounds like we'd be stalling the whole render process each time we try to lock the VB to copy another block of geometry into it. Or is this lock conflict not as big as it sounds? Am I missing some intermediate step that makes this work more smoothly?

Share this post


Link to post
Share on other sites
Advertisement
Some time ago, trying to use a static VB for my cache, I observed framerate hiccups corresponding to VB writes. Like you, I assumed a stall situation. At the time, I just switched to a dynamic VB as a temporary solution.

You would think a driver could avoid a stall by noticing that you're only locking a tiny, currently-not-in-use portion of the static VB. Maybe some drivers actually do this?

One idea I considered was to have two caches, corresponding to even and odd frames. Certainly this would be wasteful, but you could potentially avoid ever writing to and rendering from a cache VB in the same frame.

Another question for you guys, possibly relevant to the static-versus-dynamic debate:
How big is your cache compared to a single frame's (average? worst-case?) vertex count? 2x? 10x?

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!