Bindless Textures support?

I have not used OpenGL extensions in a long time, so I am not sure what the status of support for this is:

Does ARB mean it is guaranteed to be supported with OpenGL 4.0?

No. Bindless textures is not core in any OpenGL version.

It’s not exactly unsupported for recent hardware.

Great, so new Nvidia and new AMD cards support it. How about Intel? And how does the support level overlap with Vulkan? More favorable, less favorable, or about the same?

All of that information can be found on the page I linked to. Well, not the Vulkan stuff, but Vulkan is implementable on anything that allows GL 4.x.

Also, I’m not really sure why the Vulkan thing would matter. If you want to use Vulkan, it’s probably going to be for something more than just how it uses textures. It’d be about multithreading performance and many other things that OpenGL just can’t do. I don’t know why you would want to compare them.

Well, one reason is for folks thinking about rewriting/extending their OpenGL-based apps or engine to support Vulkan.

If this is a potential in their future dev plan, to make their lives easier down-the-road they should probably avoid picking up a feature that OpenGL supports widely but Vulkan does not.

Related: Where are bindless extensions for Vulkan? #871, Pointers for GLSL

In Vulkan, it sounds like support for bindless buffer handles was just released last month, but we may still be waiting on bindless image/texture support.

Exactly. I am trying to figure out if bindless textures are a realistic option for a commercial product to be released in one year, or if I should stick with array textures.

Other related posts:

But that’s not what I was asking about. Whether bindless textures are a practically available tool for OpenGL has nothing to do with whether Vulkan is a practically available tool.

Rewriting your OpenGL application to use bindless textures is completely orthogonal to rewriting your application to use Vulkan. With arrays of samplers (note: not the same thing as an array texture), Vulkan can accomplish the effective equivalent of bindless textures: the ability to pass a number to a shader, which gets converted into a texture via some mechanism.

See, in the Vulkan resource model, layout(set = 0, descriptor = 0) sampler2d arr[2048]; takes up exactly one descriptor. So, while there is a limit on the number of samplers you can have, that limit is not the same as the limit on the number of descriptors you can have. And for desktop GPUs, that limit is usually quite generous. Even 768 (the common Intel number for recent Vulkan implementations) is a pretty big number of textures to use.

In OpenGL, bindless textures work implicitly via residency and handles. In Vulkan, you accomplish the same thing explicitly. You have an array of samplers in a descriptor. Making a texture “resident” means putting that texture in the array. Your “handles” now become indices into that array representing that texture, and this index can be passed to the shader through any means that can generate an integer. The only difference is that, in Vulkan, “handles” are tied to “residency” unlike OpenGL.

So if you rewrite your application to use OpenGL bindless textures, and then later you want to rewrite your application to use Vulkan, your texture handling system won’t need to change much.

Good to know. Thanks for the info!

Thanks for clarifying that one! I definitely missed that subtlety.

So long as there are no restrictions on the internal formats, resolutions, MIPmaps, nor sampler parameters of the textures placed in a Vulkan “array of samplers”, that certainly sounds like it provides roughly equivalent functionality (given that Vulkan already gives you explicit control of residency).