No, it’s not that kind of bondage we’re talking about. When using OpenGL 4.5 or newer, Triton has the ability to take advantage of “bindless graphics” that use native GPU addresses, instead of handles for resources that must be looked up and validated by the driver. This offers some performance benefit, and also gets us a closer to an architecture that’s ready for Vulkan.

This feature is disabled by default; the relevant settings in the Resources/Triton.config file are:


If set to “yes”, these settings enable bindless textures, UBO’s, and VBO’s respectively. Their usage requires use of the OPENGL_4_5 or newer renderer type with Triton (specified in Environment::Initialize()), and bindless UBO’s and VBO’s rely on NVidia-specific extensions that may not be present on the systems you are targeting. That’s why they are disabled by default. If however you control the configuration of the systems you are deploying your software to and they are compatible with NVidia’s bindless extensions, you can test enabling these options in your deployments. Bindless textures rely on the availability of the GL_ARB_bindless_texture extension; bindless UBO’s rely on GL_ARB_uniform_buffer_object, GL_NV_vertex_buffer_unified_memory and GL_NV_shader_buffer_load; and bindless VBO’s rely on GL_NV_vertex_buffer_unified_memory and GL_NV_shader_buffer_load.

If you’re targeting systems that can be expected to have reasonably current video drivers, enabling bindless textures is probably a safe thing to do. Bindless uniform buffer objects and vertex buffers do involve NVidia-specific extensions, and should be tested carefully on the systems you intend to support. We’ve heard reports of some drivers incorrectly reporting that they support these extensions when they really don’t. This is still bleeding-edge stuff, but it’s the direction 3D graphics are headed – and Triton is ready for it.