Descriptor indexing?

[gwaldron]

Does VSG have any support (existing or planned) for Descriptor Indexing (bindless resources)? I didn't find anything in the repo so far.
https://docs.vulkan.org/samples/latest/samples/extensions/descriptor_indexing/README.html

Example use case: I want to draw thousands of icons, with a variety of different shared textures. Instances are dynamic and they come and go over time. Rather than sort each instance into a specific pipelines, or try to maintain a texture atlas, it would be flexible to use bindless textures and encode each icon's texture handle/id in its instancing data.

Thanks Robert ;)

[AnyOldName3]

Can't you already put multiple images in a vsg::DescriptorImage? Everything else for bindless textures in Vulkan is shader-side, so doesn't need explicit support from the VSG.

[gwaldron]

Well yes, and this gives you an array of textures in the shader. And that works as long as your array indexes are dynamically uniform, according to the literature.

What I don't know is whether my use case I described results in a dynamically uniform index. I would store a large set of structs in an SSBO:

struct Instance {
    mat4 modelView;
    int textureIndex;
};

These instances may by in a SSBO, or they might come out of a GPU culling compute shader.
In those cases is the textureIndex dynamically uniform? Am I even asking the right question?

Just want to make sure I'm on the right track before writing a bunch of code that doesn't work :)

[AnyOldName3]

The rules for what counts as dynamically uniform are covered in the Vulkan documentation page you linked, and they're Vulkan rules, not VSG rules. (Technically, they're the same rules as for OpenGL and Direct3D, so they're not Vulkan-specific.)

A good rule of thumb is that if something doesn't have the same value for every vertex and every fragment in a draw call, it's not dynamically uniform. There are exceptions (e.g. the documentation you linked says that with multi-draw indirect, it only needs to be consistent across as single gl_DrawID), so it's worth looking at the full rules, though.

If things aren't dynamically uniform, then it's not the end of the world to use GL_EXT_nonuniform_qualifier. VK_EXT_descriptor_indexing (the CPU-side extension that exposes the presence of the GLSL/SPIR-V feature) is widely supported on desktop platforms.

[robertosfield]

I haven't dabbled with bindless resources so can't comment on the specifics. I can't investigate the topic right now as I have too much unpaid work to complete for the next VSG release so need to keep my head down and just work through it so I can get back to earning a living.

The only thing I would add is, if Chris is right then it's just a matter of shaders, you may still need to enable the extension. There are several vsgExamples that check for and enable extensions, the vsgmeshshader example is the most extensive one so a good one to look at how vsg::DeviceFeatures is handled.

I have to say though, an example that illustrates how descriptor indexing would be an excellent addition, so if anyone fancies tackling that please go for it. And if you struggle to get it working you can always share it so others can fill in the missing bits.

[gwaldron]

Thanks for your thoughts.
I am confident enough in the approach to at least give it a try; will report back.

[gwaldron]

I promised to report back:

I managed to get this working. The array-of-samplers approach works fine without any additional extensions. I'm populating a cull buffer SSBO with instances, using a compute shader to cull the instances into a draw list, and then using DrawIndexedIndirect to render the final data. All this works.

The only problem is that instances flicker in and out of existence randomly from frame to frame. Perhaps a sync problem? Perhaps the SSBOs are not protected from simultaneous access, and one stage is overwriting data while the other is still using it? Indeed, inserting a viewer->deviceWaitIdle() into the main loop makes the problem go away. I've attempted to employ PipelineBarriers without any luck but this is probably more down to my lack of experience with Vulkan combined with not being sure what the actual problem is.

I will keep hammering away, in the meantime always open to tips and advice. Thanks all.

[AnyOldName3]

Enabling the synchronisation-related validation layers might identify exactly where the problem's happening.