How OpenGL drivers caches textures in VRAM

I'm not sure, but i assume it depends on which GL version / features you actually use.

For example, i remember Tim Sweeney saying the reason he used DX for Unreal was GLs requirement to have copies of all textures on system ram.
OpenGL required this as a fallback in case VRAM was not enough, while on DX you could query available VRAM to upload textures at as high as possible resolutions, avoiding a need for copies on system ram.
So in worst cases the GPU did read textures over slow AGP/PCI bus, which technically worked, but was unpracticaly slow for games anyway.

This flaw has been fixed with later more modern GL versions.
I remember there were new API functions for texture objects, but i forgot all the details.

There should be better answers, but probably you want to make sure you do (or the driver does) not keep copies of textures on system ram around. You want to upload them to VRAM just once explicitly and free up any copies right after the upload, iirc.

It's an implementation detail. OpenGL doesn't specify the existence of graphics hardware, nor VRAM. There are software-only implementations like the Mesa drivers, and there have been systems other than the PC like those from old SGI machines that had all memory accessible to graphics operations. That was one of the benefits of the Onyx and O2 workstations back in the day.

Specific drivers, like those from NVidia, tend to do lazy loading to the hardware and cache it there, meaning it will delay transferring until actually needed, and once it's there leave it there until it's either unused or forced out by other items getting loaded. They maintain a copy of the data in main memory in addition to transferring to the card, which may be loaded and unloaded from the card as needed.

frob said:

It's an implementation detail. OpenGL doesn't specify the existence of graphics hardware, nor VRAM. There are software-only implementations like the Mesa drivers, and there have been systems other than the PC like those from old SGI machines that had all memory accessible to graphics operations. That was one of the benefits of the Onyx and O2 workstations back in the day.

Specific drivers, like those from NVidia, tend to do lazy loading to the hardware and cache it there, meaning it will delay transferring until actually needed, and once it's there leave it there until it's either unused or forced out by other items getting loaded. They maintain a copy of the data in main memory in addition to transferring to the card, which may be loaded and unloaded from the card as needed.

Thanks for the answer.

I would assume current drivers for AMD and Intel would do the same thing. Do you know if Nvidia drivers are smart enough to load only parts of the texture to VRAM for very large textures, or is it strictly texture by texture?

You can query GL_MAX_TEXTURE_SIZE which depends on the system, likely currently 16K x 16K resolution textures. It is an implementation value, and will vary with the card and the driver.

The part about only referencing part of it, how exactly would you expect it to work? You map the texture. Shaders might reference it, texture coordinates reference it. Do you expect something would somehow know or predict the position the shader will output for texture coordinates? How would you predict a shader will output one range of (s, t) results but not a different range?

@frob I guess it would have to load the entire texture into VRAM

The OpenGL specification does not mandate any memory management by the implementation. However, if you read the specification/documentation for any entry point that deals with memory, it will state the memory specific behavior(s) or associated ‘exception behavior’. In any case, DO NOT trust the driver to do ANY sort of memory management on your behalf. This is the primary reason why there are multiple variation of streaming data to the GPU via .

Pretty much, yeah. glBindTexture alone doesn't mean “this is now in VRAM forever”. The driver decides when it actually needs to live there. It's more like "best effort" caching than something you can rely on exactly.

OpenGL manages the texture memory for you. You don't have control how and where the texture is stored. Its not your concern. OpenGL is a higher level API than vulkan and other extreme low level APIs, and you don't access or manage the video memory directly.

If you think OpenGL manages texture memory for you, then try loading a 8 GB texture and validate what happens. Being able to load a texture into available GPU memory is not memory management, in the full extent of the word. Here the reference to memory management is akin to how the OS manages host memory, which involves multiple memory hierarchy and caches. Ex, If you oversubcribe host memory, the OS will be nice and allow for full backing via the page file etc. OpenGL does not do this.

It does. Except for the page file - that will be result of your os swapping it out from your applications address space to the disk.