[QUOTE=zipponwindproof;1293165]
Now I am loading textures and unloading, so I should preallocate lets say 1GB of vram (depending on my game scenes?) using GL_ARB_texture_storage and then subload texture there? [/QUOTE]
It’s up to you. Your game could carve out a fixed amount of GPU RAM for textures in some way, or it could have that amount be dynamic based on how much GPU memory is available on the GPU.
And when I unload it, I dont use glDeleteTextures at all and still keep it in memory, but mark as ‘unloaded’ and reuse that memory for other texture?
Exactly.
What should I do when I exceed 1GB of ‘preloaded’ memory and all textures are occupied, so no free buffer?
Should I approximate my scene somehow and force some distance-check of entities to unload textures to always have free slots for new models (textures) to be loaded?
That’s up to you. However, a tip (that may be obvious). Standardizing your textures’ internal formats and resolutions to a small set will help avoid situations like this where you’ve got free textures allocated, but they’re not the format you need.
You mean this I should not use?
glMapBuffer(GL_PIXEL_UNPACK_BUFFER, GL_WRITE_ONLY);
Right.
Think about this from the driver’s perspective. The CPU (your app + the driver) have queued up lots of GL commands ahead of where the GPU is executing now. Suppose that that buffer object that you’re mapping on the CPU “now” is going to be read in the future by the GPU once some previously queued commands get to the head of the queue. When that happens, on the GPU side, the buffer object must have the contents that it had “before” the MapBuffer and modify that you’re now doing on the CPU. So what’s the driver to do?
Some drivers just block in your call to MapBuffer in this case, waiting for already-queued references to that buffer object to clear the GPU before the CPU is allowed to change the buffer object. That means your GL thread running on the CPU can’t perform other work until it unblocks, meaning that your GL thread doesn’t have as much frame time to submit everything for a frame.
Proper use of PERSISTENT/COHERENT (or UNSYNCHRONIZED) buffer maps will avoid this internal driver synchronization, giving you more time to submit content to the GPU.
Related: See this chapter from OpenGL Insights: Asynchronous Buffer Transfers (OpenGL Insights). As a teaser for what’s inside, see the method timing table at the end. This book was published before PERSISTENT/COHERENT buffer maps were available, but all the other usual buffer update methods are included (what you’re doing is effectively the “Write” line, though with glMapBufferRange instead). Keep in mind that through that this reflects GL driver performance 6 years ago. So while the numbers would look different for drivers today, the concepts and underlying issues are the same.
I see persistent mapping is Core since version 4.4. I would like to go with 4.2 max.
Functionality is often available as extensions before it hits the core OpenGL spec. If 4.4 is too high a bar for some reason, you could access this through ARB_buffer_storage instead.
Here’s are driver reports which have support for that extension: GL_ARB_buffer_storage reports (gpuinfo.org)