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:
[ol][li] 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).[/ol][/li]Thanks for any insight.
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.