Push constants let us send a small amount of data (it has a limited size) to the shader, in a very simple and performant way. Push constants can send data to any shader stage (both vertex and fragment shaders), and are stored in the command buffer itself.
To use push constants, you first need to set their size (in each stage) when you create a VkPipelineLayout. Then, using the command vkCmdPushConstants, the data will be embedded into the command buffer, and will be accessible from the shader. We are going to use them for transformation matrices, to be able to move objects around and do proper 3d rendering. To start, we are going to use it to move the triangle we are rendering.
First, there’s no need to put things like “[REQUEST]” and “[BUG]” or whatever in your title. We can read your title and figure out what kind of thing it is.
As for your question… what is it about the text you quoted that you don’t understand? That is, what do you mean by “what is a push constant”? I could answer that, but my answer would be essentially a differently-worded version of what you quoted.
So it would be better to just say what it is you don’t understand.
Push constants are a way to transmit data to a shader. So there are two parts to them: the host code that will transmit information to the shader, and the in-shader definition that will receive them.
Shaders in Vulkan usually access information stored in memory through a descriptor resource. Push constants aren’t descriptors though; they live outside of that system.
Instead of having a piece of user-allocated memory storage, push constant storage is ephemeral. When you bind a program pipeline, you are effectively creating a few bytes of push constant storage memory. You can upload CPU data to this memory via vkCmdPushConstants. Rendering or dispatch commands issued after this function can read from this memory through push constant uniform values. No synchronization is needed, as vkCmdPushConstants effectively executes immediately (within the command buffer).
Assuming you’re using GLSL to define your shaders, you can access push constants from your shader with the push_constantlayout qualifier applied to a uniform block:
This is a uniform block, so the data you upload needs to match its memory layout. But the layout of a push constant block fits GLSL’s std430 layout rules, not the usual std140 layout rules used by regular UBOs. That doesn’t matter in this case; either way, the above uniform block takes up 20 bytes (16 for variable1, 4 for variable2).
So when you call vkCmdPushConstants, you need to upload memory containing 20 bytes, which represent 5 contiguous float objects. You also need to specify which shader stage(s) can read from that push constant range.
Also, when creating your pipeline (or rather, the pipeline layout your pipeline uses), you need to tell it how many bytes of push constant each shader stage can access. While this is technically part of your shaders, it needs to be stated directly at pipeline creation time.
You are the one claiming that these tags are useful. As the rest of the forum users don’t use them, the burden of proving that these tags are useful is on you, not on us.
I have claimed no such thing. I asked you what it was you didn’t understand about them. I asked you to clarify your question. That’s not a claim that the term is “clear” or anything of the kind; merely that I do not understand what exactly it is you’re trying to figure out.
Furthermore, you’re dodging my main point: you did not do the searches you claimed you did. The presence of “so many queries” makes it highly unlikely that genuine effort to search for tutorials on the topic would not have led you to them.
Are you saying that your question really was, “please write me a Wiki article/tutorial on push constants”? Because that’s a pretty big thing to ask people for, and if that’s what you want, you should be direct and up-front about it.
The closest thing OpenGL has would be a non-block-scoped uniform (that isn’t of an opaque type, those are descriptors in Vulkan). But that’s primarily relative to the ease of changing their values compared to the alternatives, not the internal implementation, mechanism for specification, or its relative limitations.
So it would be better to say that OpenGL doesn’t really have an “equivalent concept”. There are some similarities between certain OpenGL constructs, but that’s about it.
There are many good sources of information on Khronos Technology available on the web. You should check these before posting.
Google is your friend. Or Bing, if you prefer. Or whatever searching service you prefer; it doesn’t matter. It would be best for all involved if your question could not be answered via a simple search based on the terms you’re interested in.
I do not think that this is an unreasonable expectation, nor does it qualify as “remove/bar people from learning Vulkan”.