PDA

View Full Version : VBO creation and management policy



Dark Photon
11-15-2007, 04:16 PM
With the pending flip to GL3 and VBOs being the sole option for vertex data, how are these "supposed" to be used globally (i.e. for everything)?

Questions:
Is the amount of VBO memory you can consume limited by GPU memory (less FB, textures, etc.), ...or by CPU memory, where the driver quietly shuffles VBO vertex data on/off the GPU based on VBO "hit rates"? Are real-time geometry paging apps (think flight sims, large-level games, etc.) supposed to "carve out" a large chunk of GPU memory on startup by preallocating VBOs of various sizes, and dynamically portion pieces at run-time to rendering the huge and dynamically-changing set of geometry ...or, should apps just alloc and free VBOs for individual drawables at run-time presuming the GL driver can be much smarter about this "memory management" than it can).
Thanks for any insight.

Korval
11-15-2007, 05:15 PM
Is the amount of VBO memory you can consume limited by GPU memory (less FB, textures, etc.), ...or by CPU memory, where the driver quietly shuffles VBO vertex data on/off the GPU based on VBO "hit rates"?

That's up to the driver.


Are real-time geometry paging apps (think flight sims, large-level games, etc.) supposed to "carve out" a large chunk of GPU memory on startup by preallocating VBOs of various sizes, and dynamically portion pieces at run-time to rendering the huge and dynamically-changing set of geometry ...or, should apps just alloc and free VBOs for individual drawables at run-time presuming the GL driver can be much smarter about this "memory management" than it can).

That's up to them. However, I imagine that most of these are doing one of these already. And GL 3.0 will have a number of mapping options, so mapping will become a more viable opportunity in the future.