vkCmdDrawIndexedIndirect

[waman]

This is not so much something that doesn’t work but rather something that does work when I have read in various places it should not and seen tutorials/code by people who compared to me are not noobs in terms of graphics…

Reason I get worried is that it makes me think it’s something I got lucky with (driver support) but could go wrong if done on different hardware.

ok, so it has been said that vkCmdDrawIndexedIndirect seems to lack the count and for drawing one still has to have a loop over the buffer or use some extension or have support of Vulkan 1.2 or so ( vkCmdDrawIndexedIndirectCount).

yet I can use the command with a 0 offset and walk all the draw commands in the buffer (using the drawcount parameter). that said I can fill the buffer to with draw commands and the relevant info to do instanced drawing of all my objects sorted my meshes.

what I needed, however, was gl_DrawIDARB and GL_ARB_shader_draw_parameters on the shader side and VK_KHR_shader_draw_parameters on the vulkan code side, to be able to extract my indices/offsets into other SSBOs.

now I “believe” that with glsl version 460 I can use gl_DrawID, not sure if I have to require a higher vulkan api version as well, these are things that I find really hard to get some info about, especially on the shader side, things get renamed, promoted, etc. but the lack of good info I find makes it hard to architect your code - shading is my weak spot anyhow.

ok, lot of rambling, so I was wondering if I can rely on such a solution to work fairly well across hardware, and is it generally better to require higher glsl versions, or rely on extensions, are there a lot of hardware dependencies with version differences or can I hope that by and large it’s about driver implementation to support them, same goes for the Vulkan API, can I safely “hope” most setups will support a certain version.

while I don’t want/need guarantees for things to work, I do want to build something that I myself can use on different hardware/GPUs that is not totally outdated, so I aim for the greatest common divisor in a sense.

[Alfonse_Reinheart]

@waman

so it has been said that vkCmdDrawIndexedIndirect seems to lack the count and for drawing one still has to have a loop over the buffer

The only thing vkCmdDrawIndexedIndirectCount does is allow the draw count to be sourced from a buffer (and therefore generated by GPU commands), rather than being exclusively provided by the CPU. So you probably misunderstood what someone was saying.

@waman

now I “believe” that with glsl version 460 I can use gl_DrawID

Vulkan does not consume GLSL; it consumes SPIR-V. So GLSL versions are irrelevant. The SPIR-V decoration DrawIndex is provided by Vulkan 1.1 as a core feature (but you do have to check to see if it is available. Though it is widely available ).

[waman]

@Alfonse_Reinheart

The only thing vkCmdDrawIndexedIndirectCount does is allow the draw count to be sourced from a buffer (and therefore generated by GPU commands), rather than being exclusively provided by the CPU. So you probably misunderstood what someone was saying.

Ah, I see. Looking at the online docs it occurs to me that my original confusion came from multiDrawIndirect which is supposed to be enabled.

Thank you for that clarification, I was going to experiment with writing indirect draw buffers from a compute shader next. So, again, this may be a naive question, I’m trying to gain some understanding, but using a compute shader I can record those indirect draw buffers, right? So vkCmdDrawIndexedIndirectCount would in that case be the means to work with a different count of recorded draw instructions?

@Alfonse_Reinheart

Vulkan does not consume GLSL; it consumes SPIR-V. So GLSL versions are irrelevant. The SPIR-V decoration DrawIndex is provided by Vulkan 1.1 as a core feature (but you do have to check to see if it is available. Though it is widely available ).

Ok, so I get what you are saying, and that is reassuring in terms of compatibility, although I don’t usually go and check whether the tool in question (glsc) decorates accordingly

[theRPGmaster]

While it’s true Vulkan consumes SPIR-V, for example, the memory layout qualifier used in GLSL does affect shader module runtime behavior. I recently switched to using the std430 layout, using the GL_EXT_scalar_block_layout extension (GLSL) and the VK_uniform_buffer_standard_layout device feature (Vulkan)
This was to eliminate the need for padding in arrays inside uniform buffers. It took me a while to figure that out, so it’s worth mentioning, hopefully it’ll be useful to someone.