anyway to specify descriptor set's set value when creating pipeline layout

if let say my shader is using:

layout(set = 1, binding = 0) uniform UniformBufferObject { … }
and
layout(set = 5, binding = 0) uniform UniformBufferObject { … }

when creating my pipeline layout there isn’t anyway for me to change the ‘set’ value it seems to be using set value starting from 0 till N-1 where N is the amount of descriptor set i passed in.

so when creating my pipeline layout i need to pass in 6 valid descriptor set (can’t use VK_NULL_HANDLE either for unused) in this case though set 0 and set 2 to 4 aren’t used in the shader?

SPIR-V doesn’t allow specialization constants to set decorations like DescriptorSet. As such, you cannot change what descriptor sets are used by a shader module after having built it.

A better question is why you are using such sparse descriptor sets to begin with. I can understand having sets based on frequency, but I don’t understand why you feel the need to have 6 sets.

SPIR-V doesn’t allow specialization constants to set decorations like DescriptorSet. As such, you cannot change what descriptor sets are used by a shader module after having built it.

no, i’m not trying to change the descriptor set after building the shader… what i’m saying is that my shader set value is sparse is there anyway for me to set them up by specifying them on pipeline layout creation?

A better question is why you are using such sparse descriptor sets to begin with

i’m using it as a sparse descriptor set cause each of my descriptor set are defined in their own shader file and i #include those shader file in order to have those uniform just like how we include vector header or list header from the stl
if the descriptor set isn’t sparse, i’ll need to define their value depending on the ordering of the inclusion which is doable but troublesome.

I can understand having sets based on frequency, but I don’t understand why you feel the need to have 6 sets.

because i have many different frequency of descriptor set used in my engine… it could be more i just don’t use them all in one shader file

Pipeline layout creation is separate from in-shader descriptor stuff. One step cannot influence the other, but both steps have to agree. So if your shader says to use set 5, your pipeline layout has to have that in descriptor set 5. There is no other means for connecting the two.

Not unless you actually make it. You could certainly patch a SPIR-V binary to change what descriptor set is there based on what pipeline layout you want to use.

How are you #including something in a language that doesn’t offer that feature (like GLSL or SPIR-V)?

If you’ve written your own shading language, or are heavily modding one like GLSL, then you could deal with this yourself. This goes with the SPIR-V patching I mentioned earlier. You would need some way to assign a descriptor set a name. When you build a pipeline layout, you would match the sets used there with the name of the set. Your shader loading and processing system would be given a layout to load a shader module against, and it would match descriptor set names against the indices of their use in a given pipeline layout.

How many different frequencies could you possibly have? There’s per-rendering-pass (things like global light locations, shadow maps, perspective matrix, etc), per-group-of-objects/instances (shared textures for a large group of objects, lights that cover this group of objects, etc), and per-instance (model-to-camera matrix, etc). I could see at most one or two more divisions on top of that.

It seems more like your descriptor sets are too fine-grained.

The problem isn’t the sparseness per-se. The problem is the fact that you’re using at least 6 descriptor set indices, and (among other things) the Vulkan specification only guarantees you four. Some implementations give you 8.

i know i can deal with it myself, i’m just checking if there’s a better alternative where i don’t have to deal with it.

How many different frequencies could you possibly have? There’s per-rendering-pass (things like global light locations, shadow maps, perspective matrix, etc), per-group-of-objects/instances (shared textures for a large group of objects, lights that cover this group of objects, etc), and per-instance (model-to-camera matrix, etc). I could see at most one or two more divisions on top of that.

It seems more like your descriptor sets are too fine-grained.

because the same descriptor set can be used differently in many different shader, and in that case now it will need a different set number if it requires a different combination of descriptor set. take for instance i have a shader that does lighting and another that doesn’t do lighting, since lighting uniform seldom change it’s in the earlier set number, the uniform used for both shader are the same for the per object frequency (the world matrix) and now i’ll need a different set number, that’s why i would prefer it sparse.

The problem isn’t the sparseness per-se. The problem is the fact that you’re using at least 6 descriptor set indices, and (among other things) the Vulkan specification only guarantees you four. Some implementations give you 8.

good to know