GLSL in Vulkan requires me to do something like:
layout(binding = 0) buffer A {
uniform float B;
} C;
Is there a document somewhere that explains the exact meaning of A, B, and C, what namespace each one is in, which of A, B and C are allowed to have the same name and if not why not? A BNF would give me a warm fuzzy feeling if one exists.
I'm finding tutorials giving examples of A, B and C but never, like… a definition.
Meanwhile this block-based approach creates a situation where the name I use to upload a variable on the code side is different from the name I access it by on the shader side and it's driving me vaguely nuts. I'm trying to figure out a way of thinking about this that doesn't feel deeply wrong to me. ("Update block FloorDepth to set uniform floorDepth" would be an example of something that feels deeply wrong.)
@mcc you shouldn't be doing it by name, the block approach is so you can map CPU memory to shader memory directly
@ivan The API I am using does not support addressing blocks by binding #, therefore I am addressing them by name. But also addressing them by binding # sounds awful.
@mcc Ah I see. I find the binding # approach quite a bit better in that you can just map a CPU struct to shader memory and then just set stuff in the struct directly without ever dealing with strings (though there is some memory alignment stuff to keep in mind).
@ivan I am writing in a garbage collected language (Lua, as it happens) and "map a CPU struct to shader memory" is not a meaningful phrase in my current context. The API offers a way to instantiate a data buffer, modify its contents directly using luajit ffi, and then upload that buffer *as a block*, but it does not allow doing so to an entire descriptor set at once. And if it could, I'm not sure I'd want it to… * _ *
@mcc you keep a handle of a VkDeviceMemory which is bound to a descriptor set at a specific location, then you just map it to CPU memory, copy it and unbind when you want to update shader data.
@mcc in my framework, i just have a templated buffer struct that wraps around a C++ struct that handles all of that, so all you do is just update your CPU data and call update() on it and it does the GPU memory update. if you have multiple frames in flight you also need to keep a separate device memory for each frame, so it has to handle all of that.
@ivan well, how do you tell it what buffer it is you're mapping? by binding number?