Using multiple descriptor sets without explicit "set" storage in GLSL?

1
votes

I'm quite new to Vulkan and I try to understand the descriptor set feature.

For a given shader, I would like to bind my uniforms separately at different steps during rendering :

  • per subpass binding (ex: camera stuff)

  • per material binding (ex: texture stuff)

  • per object binding (ex: gameplay instance stuff)

But I would like to do automatic grouping of uniforms by 'set' (I don't want the user to be forced to know what variable should go in which set).

Is it possible to create multiple Descriptor sets without explicitely marking the uniforms in the GLSL shader with "set = X"? Can we do this "grouping" manually with the Vulkan API?

1
vulkan
Overall, I think that it is wrong-headed to try to make shaders which are ignorant of how they will be used. After all, the user has to know which descriptor index to give the particular variable, right? If they get that wrong, then their shader doesn't work. If they already have to follow a specific convention, what's one more value added to that convention? – Nicol Bolas
What I try to achieve is 'no convention at all' at the shader code level. The shader dev only wants the uniform as if they were parameters of a function in fact. The engine optimization mechanics behind must not be their concern.. I was willing to plug afterwards the uniforms with their role (inside an editor for example), like 'camProj' <-> ENGINE_CAMERA_PROJECTION and build my self the descriptor sets matching my rendering pipeline, but don't want to imply the shader developer inside all of this. – Juicebox
"What I try to achieve is 'no convention at all' at the shader code level." But you will have one. That's what function parameters are: a convention. You specify their position and type, and that is the convention for calling that function. If the shader has to specify descriptor or a specific name that has some meaning, then there is a convention that they must follow. What you're talking about ultimately boils down to some kind of convention, and if try to abstract it into a reasonable alternative, you're now talking about a completely separate shader language. – Nicol Bolas
Indeed there is always conventions, but what I find non-sense is to put it at the wrong place, where it is not necessary for the user. To continue with the function metaphore, it is like if in C++ you were asking to tell in which registers the arguments should go. You just want to use the arguments as you expect they will be passed, the 'how' is somewhat not really your concern. I like the way vulkan is low level, but I'm a bit disappointed how GLSL has been connected with this. To me it should have been a SPIR-V compiler option (maybe it is ??), not the shader dev responsability. – Juicebox
What should have been a SPIR-V compiler option? The ability to specify vital information about the nature of the data within the shader itself? A low-level API should be low level; that means that everything involved with it knows what's going on. And if you want to prevent someone from knowing what's going on, then it's up to you to build that layer. And I still don't see why you're fine with descriptor yet not set, even though it makes absolutely no sense to set one without setting the other. It's like being fine with latitude, but not longitude. – Nicol Bolas

1 Answers

3
votes

Is it possible to create multiple Descriptor sets without explicitely marking the uniforms in the GLSL shader with "set = X" ?

Not unless you hack the shader code itself before giving it to Vulkan. As an explicit API, Vulkan expects all contributors to its data to know what's going on. So if you don't want your users to know what's going on, then you need to modify their shaders before sending them along to Vulkan.