Bindless Textures - resident textures Limits

[Dark_Photon]

@david_bp

From Bindless Texture documentation, it is written the following about maximum amount of resident textures:

The amount of storage available for resident images/textures may be less than the total storage for textures that is available. …

Is there a way to get this limit for the current hardware? …
I didn’t find any other details about this limit than the quote above. …

I have 16GB dedicated memory on my GPU.
Making texture resident works well, until I reach around 1.6GB of texture data.
From this point, glMakeTextureHandleResidentARB silently fail for the following texture handles:

• no error, but all textures created after that contain only zero values
• and if I call glIsTextureHandleResidentARB after I made the texture resident, it returns false
  …
  I don’t see what else could make this scenario fail / what other limit I might miss.

Your second result sound familiar

Are you on Windows?

The limit you’re likely hitting is not the total amount of resident storage (particularly given your GPU mem stats), but instead the maximum number of graphics driver allocations of GPU memory (…if you’re on Windows). This applies to not just bindless textures but across all driver allocations.

On Windows, the limited imposed by the Microsoft WDDM on your graphics driver is 4096 maximum allocations. On Linux, this limit is 4 billion. You can query this limit under Vulkan as VkPhysicalDeviceLimits::maxMemoryAllocationCount. See:

• maxMemoryAllocationCount - Vulkan Hardware Database by Sascha Willems

I don’t know how to query it in GL, but it’s less useful there because you really don’t know what physical GPU allocations your graphics driver is making behind-the-scenes anyway (e.g. streaming buffers for client arrays emulation, ghosted textures to avoid synchronization on updates, texture transfer buffers, etc.)

When not using bindless textures, the workflow run just fine, regardless of the amount of textures (as long at it fits into GPU memory). And when using fewer texutres, bindless textures work just fine as well.

You should be able to get around this limit by pooling your textures into 2D texture arrays. This should consolidate multiple physical texture block allocations into a single texture block allocation (or at least N, where N is the number of texture levels).

On that note, Texture Views may be useful here to make portions of a 2D texture array appear as separate 2D textures. However, I don’t know for sure how this interacts with physical device allocations (maxMemoryAllocationLimit). My “hope” would be that these don’t cost you any extra physical device allocations, …but I don’t know for sure. If this’d be useful to you, you could try it and see.

Oh also… Are you checking for GL errors? If you’re running on an NVIDIA GPU driver, and you have a GL debug message callback plugged in, then when you hit the limit in your app, you may get detailed GL error message info callback from the driver with more details on what limit you hit. For instance, I’ve seen these passed back from NVIDIA, possibly for hitting a limit on the max buffers or textures resident:

GL_OUT_OF_MEMORY error generated. Exceeded buffer residency limits - buffer count
GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.