Do OpenGL buffers overflow to CPU memory?

This is a question about OpenGL buffers and memory. My game world is mid-sized, one contiguous space, unchanging, and only partially visible from any position.

Will modern OpenGL overflow buffers into CPU memory?

And if so, can I just allocate buffers (vertex and texture) for all of it, and adjust my draw calls to skip non-visible areas, and let OpenGL pull buffers into GPU as needed, hopefully minimizing thrashing? (Or does OpenGL just fail on the allocate after a while?)

EDIT: The above was ambiguous. But maybe both variations are interesting.

1. Could I just allocate one huge vertex buffer and a few giant textures, and hope that OpenGL moves parts of it in and out of the GPU as needed, and maybe enough early depth-testing lets it skip some of the texture drawing...

2. Could I have a handful, or maybe a lot, of "sensibly-sized" vertex and texture buffers, but only glDrawXxx() some of them on each frame? In that case, would OpenGL move them up and down from the GPU, maybe in a least-recently-used sort of way?

• The topic of how to juggle the visible data for your world (given that OpenGL won't do it for you) is broad, and really a separate area of discussion (there's a few questions about world culling / streaming floating around the site -- particularly as related to Minecraft-style worlds, though the techniques are still appropriate). I removed that part from your question; you should browse the related questions on the site and post a new one if none of them help you with the specific world streaming problem you are having. – user1430 Oct 2 '14 at 15:51
• Thanks, question is tighter now. I was asking more about the "paging strategy" rather than the "visibility" strategy. (My world is kind of gridlike, so visibility is not too hard here...) – david van brink Oct 2 '14 at 16:02
• Your edit introduces what is basically a new question; it's a follow-up to your original question but in the future it would be better if you just posted that as a separate question, as what you've done devalues the usefulness of this single post for the future. – user1430 Oct 3 '14 at 1:38
• Josh, thanks for your indulgence, and the excellent information too. I actually meant the 2nd case all along, but wasnt clear enough about "adjust my draw calls"... – david van brink Oct 3 '14 at 6:53
• I see; well, you should post that as a new separate question perhaps (even if this question-answer pair was not exactly what you were looking for it's a good question for the site in general). – user1430 Oct 3 '14 at 15:44

No. If you request a buffer store (via glBufferData) larger than the implementation can satisfy, you'll get a GL_OUT_OF_MEMORY error. Buffers may be temporarily (or permanently) backed by CPU memory depending on their state, but a overly-large buffer store will never overflow out of GPU memory into CPU memory.

To handle the large volume of data you're describing, you'll want to page the relevant data for your world into the GPU buffer as it becomes needed (visible / near visible), leaving the rest resident in RAM (or on disk, if that's an option).

In response to your edit:

The first option isn't particularly viable unless all of each resource fits in GPU RAM. Otherwise you'll get out-of-memory resources trying to allocate space once you fill it up. If they do all fit, you don't need to worry about paging at all, obviously.

The second option is basically how you need to accomplish your goal: allocate smaller buffers of data and swap the contents of that data as needed. You can achieve some level of that automatically depending on how you choose to allow OpenGL to back your resources (with or without system memory), but you may also end up needing to do it yourself for optimal performance.

• I was thinking to have some number of smaller ("reasonably sized") vertex buffers to represent the world. And only call glDrawXxx on some of them. Not one giant one! Then my engine-ey job is to choose which to Draw(). Does that change the answer? – david van brink Oct 2 '14 at 22:12
• This depends on how you define "reasonably sized" (and how you define "large"). You really need to start thinking about precise figures here. – Maximus Minimus Oct 3 '14 at 0:06