Very well done, thank you for these videos. It's a minor point in this context, but I think it's worth noting that some buffers + images are too large to be loaded completely into some cache levels (usually L1). In such cases, cache misses and evictions will cause the workload to run more slowly if many buffer accesses are involved.
Thanks for pointing that out. Yes, it is true that only a part of a buffer or image is loaded into L2 and L1 caches, which in most cases will be the size of ~one cache line around the requested read/write position within that buffer or image.
Great series, thank you. Could you please explain the sentence, about images used as input attachments, "the access to an input attachment is framebuffer local, which means that only one pixel can be accessed, but not the neighbouring ones" - I don't know why that second part follows?
@ 21:34 when you say binding descriptors to one bind point, will not disturb the others. Does that mean if I bind Desc. A to set 0 in the Graphics bind point, and then bind Desc. B to set 0 in the Compute bind point, A will still be bound to set 0 in Graphics? Because later on @ 22:01 it seems like the sets are being made copies of, one for each pipeline bind point??
Awesome! SUBS! any link on how to deal on descriptor set limitation of 4096. how to draw many object without instancing, how to reuse descriptor set? it might be still use in CB in flight.
Whenever you can avoid additional resources (and hence, descriptors), I'd say you should go for it. You have mentioned instancing -- this is a great way of avoiding more descriptor sets, because you might just need one single buffer (i.e., one descriptor set) and use the gl_InstanceIndex to read the right data from that single buffer. The limits typically make sense and they are there for a reason.
I do not understand how it is possible to have multiple Draw commands after changing the descriptor set binding, yet in the shader code the `set = 2` is hard coded. While set 2 is is constantly changing?! So how can this work? Which set is actually being referred to then?
Within a command buffer, state-type commands are used to establish a certain state (e.g., binding some resource to set = 2, binding = 0) for subsequently recorded action-type commands. That state remains valid (and is used by action-type commands) until a different state is established. A shader is always hard-coded for a certain state, and the recorded state (within the command buffer) must match whatever the shader expects, otherwise there will be (validation) errors. Episode 5 has some more information about state-type commands and action-type commands.
@@johannesugb Thank you for answering! Had not expected you to still monitor new remarks 9 months after publication :*). I haven't watched episode 5 yet, nevertheless allow me to try and understand your reply already. The answer you gave just now does not alleviate my confusion. It seems to repeat what you said in the video (the first two sentences), and then repeat what I said (in sentence number three) - which is the part that I don't understand how it can work. Nl., "A shader is always hard-coded for a certain state" (this part was clear from your video) "and the recorded state (within the command buffer) must match whatever the shader expects, otherwise there will be (validation) errors" which describes my problem: how can this work? Let me try to explain why it is a problem for me: the command buffer first binds B to set=1, and then C to set=1 (as example). Therefore there is no one "the recorded state (within the command buffer)" - no "the". There are two. Since the shader is static it expects - say - C to be bound to set=1, not B. Therefore I'd expect a validation error when you bind B to set=1 in the command buffer. How is it possible that set=1 is used for multiple, different descriptor sets, while shaders always only work for one specific descriptor set (ignoring a possible compatibility)?
@@carlowood9834 Hmm, I see. I'll try to explain differently: When a command buffer is recorded, the ORDER of the recorded states and (action-type) commands matters. At recording-time of a command, the command buffer is in a certain state (e.g.: B is bound to set=1, binding=0) and for the command that is being recorded the CURRENT STATE is remembered by the command buffer. After recording the command, you'll maybe change the state (e.g., binding C to set=1, binding=0), but this does NOT affect the PREVIOUSLY recorded commands anymore. So, maybe the confusion comes from this recording-time which is relevant? This recording-time is just a concept you have to remember during command buffer RECORDING. Recording a command buffer does not yet send any instructions to the GPU, whatsoever. It only records states and commands (and their order of recording matters, as described previously). When a command buffer is at a later point submitted to the GPU for execution, all the commands are scheduled for execution on the GPU (possibly in parallel) and linked to the resources according to the state that has been remembered within the command buffer.
@@johannesugb Sorry, but I don't think you understand my problem :( I already understood all of that. It doesn't change anything though. You still bind B and (then) C, while a shader might only work when C is bound. I asked someone else (Sascha Willems) and he said that when you change descriptor set at set=1 you probably also change the shaders. But if that is the case then I had expected you to explicitly point that out, certainly after my question. So I am still as confused as before :(. Note how the answer "then also the shader module is changed", or even "the shader that expects set=1 to be C isn't *used* while B is bound" would answer my question. Say - you bind descriptor set B at set=1 and then do an action command that causes shader X to run where shader X expects set=1 to be B. Then you bind descriptor set C at set=1 *and* change the bound shader, so X is no longer bound/executed. Instead, the next action command causes a shader Y to be executed that expects set=1 to be C. If that is the answer then what is important here is that it is allowed to have a mismatch between what a shader expects/needs (shader X needs B, shader Y need C) and what is bound at a certain point during recording, just as long as you don't record an action command that causes the mismatched shader to be used.
Uniforms have two huge disadvantages over Storages. Veeery small size and no write access. Everyone tells this. I am looking for advantages of Uniforms more than month and still fail to find. Even here.
2 ปีที่แล้ว
What is this binding parameter in the glsl shader?
Do you mean the binding declaration itself (e.g., binding = 0) or a specific parameter? If you mean the former, this is the way how things are bound in Vulkan: Resources are organized into sets of resource descriptors, and within a set, a specific resource descriptor is identified by a binding id.
The auto-translated subtitles of this video are misrecognized as German, which is a bit difficult for me as my native language is not English🥲, it would be perfect if this problem can be fixed🥰
Oh really? Sorry to hear. We have to admit that we have received similar feedback already... maybe try to read up on some other beginner-level resources first (like those listed on the official Vulkan website: vulkan.org/learn#vulkan-tutorials) then come back to Episode 3.
What I do is I go between the link provided from cgtuwien and then back to this series to slowly see if there are any gaps that should be filled, since there's always something I might've missed or not understood yet. I also use the resources provided from the beginning of the series which can be helpful :)
![Writing a Vulkan renderer from scratch [Part 0]](http://i.ytimg.com/vi/OVxUsT6F93w/mqdefault.jpg)
honestly....this is the first time that part of Vulkan clicked for me. The series are really helpful in explaining Vulkan.
The BEST advanced introduce I've seen ever. Thanks for that.
Dude these lectures have been so helpful in filling in the gaps in my understanding. Big thanks!!
This is a really, really solid introduction to Vulkan, thanks a lot for this serie it really helps !
This is a truly wonderful course. Thank you very much for making it, as it's been of great help to me
This is so incredibly helpful. Thanks for sharing it publicly!
I love the diagrams on the right for Vulkan data structures, amazing work!
Very well done, thank you for these videos.
It's a minor point in this context, but I think it's worth noting that some buffers + images are too large to be loaded completely into some cache levels (usually L1). In such cases, cache misses and evictions will cause the workload to run more slowly if many buffer accesses are involved.
Thanks for pointing that out. Yes, it is true that only a part of a buffer or image is loaded into L2 and L1 caches, which in most cases will be the size of ~one cache line around the requested read/write position within that buffer or image.
Great series, thank you. Could you please explain the sentence, about images used as input attachments, "the access to an input attachment is framebuffer local, which means that only one pixel can be accessed, but not the neighbouring ones" - I don't know why that second part follows?
@ 21:34 when you say binding descriptors to one bind point, will not disturb the others. Does that mean if I bind Desc. A to set 0 in the Graphics bind point, and then bind Desc. B to set 0 in the Compute bind point, A will still be bound to set 0 in Graphics?
Because later on @ 22:01 it seems like the sets are being made copies of, one for each pipeline bind point??
19:30 lol, "exemplarily", I like it
there's so much info in the video and yet it is less than 30 minutes somehow. surprised that the whole course is barely 3 hours.
This helps me a lot.
thanks!
Awesome! SUBS! any link on how to deal on descriptor set limitation of 4096. how to draw many object without instancing, how to reuse descriptor set? it might be still use in CB in flight.
Whenever you can avoid additional resources (and hence, descriptors), I'd say you should go for it. You have mentioned instancing -- this is a great way of avoiding more descriptor sets, because you might just need one single buffer (i.e., one descriptor set) and use the gl_InstanceIndex to read the right data from that single buffer. The limits typically make sense and they are there for a reason.
youtube is recommendation system broken. I got such great content push this week.
I do not understand how it is possible to have multiple Draw commands after changing the descriptor set binding, yet in the shader code the `set = 2` is hard coded. While set 2 is is constantly changing?! So how can this work? Which set is actually being referred to then?
Within a command buffer, state-type commands are used to establish a certain state (e.g., binding some resource to set = 2, binding = 0) for subsequently recorded action-type commands. That state remains valid (and is used by action-type commands) until a different state is established. A shader is always hard-coded for a certain state, and the recorded state (within the command buffer) must match whatever the shader expects, otherwise there will be (validation) errors. Episode 5 has some more information about state-type commands and action-type commands.
@@johannesugb Thank you for answering! Had not expected you to still monitor new remarks 9 months after publication :*). I haven't watched episode 5 yet, nevertheless allow me to try and understand your reply already. The answer you gave just now does not alleviate my confusion. It seems to repeat what you said in the video (the first two sentences), and then repeat what I said (in sentence number three) - which is the part that I don't understand how it can work. Nl., "A shader is always hard-coded for a certain state" (this part was clear from your video) "and the recorded state (within the command buffer) must match whatever the shader expects, otherwise there will be (validation) errors" which describes my problem: how can this work? Let me try to explain why it is a problem for me: the command buffer first binds B to set=1, and then C to set=1 (as example). Therefore there is no one "the recorded state (within the command buffer)" - no "the". There are two. Since the shader is static it expects - say - C to be bound to set=1, not B. Therefore I'd expect a validation error when you bind B to set=1 in the command buffer. How is it possible that set=1 is used for multiple, different descriptor sets, while shaders always only work for one specific descriptor set (ignoring a possible compatibility)?
@@carlowood9834 Hmm, I see. I'll try to explain differently: When a command buffer is recorded, the ORDER of the recorded states and (action-type) commands matters. At recording-time of a command, the command buffer is in a certain state (e.g.: B is bound to set=1, binding=0) and for the command that is being recorded the CURRENT STATE is remembered by the command buffer. After recording the command, you'll maybe change the state (e.g., binding C to set=1, binding=0), but this does NOT affect the PREVIOUSLY recorded commands anymore.
So, maybe the confusion comes from this recording-time which is relevant? This recording-time is just a concept you have to remember during command buffer RECORDING. Recording a command buffer does not yet send any instructions to the GPU, whatsoever. It only records states and commands (and their order of recording matters, as described previously). When a command buffer is at a later point submitted to the GPU for execution, all the commands are scheduled for execution on the GPU (possibly in parallel) and linked to the resources according to the state that has been remembered within the command buffer.
@@johannesugb Sorry, but I don't think you understand my problem :( I already understood all of that. It doesn't change anything though. You still bind B and (then) C, while a shader might only work when C is bound. I asked someone else (Sascha Willems) and he said that when you change descriptor set at set=1 you probably also change the shaders. But if that is the case then I had expected you to explicitly point that out, certainly after my question. So I am still as confused as before :(.
Note how the answer "then also the shader module is changed", or even "the shader that expects set=1 to be C isn't *used* while B is bound" would answer my question. Say - you bind descriptor set B at set=1 and then do an action command that causes shader X to run where shader X expects set=1 to be B. Then you bind descriptor set C at set=1 *and* change the bound shader, so X is no longer bound/executed. Instead, the next action command causes a shader Y to be executed that expects set=1 to be C. If that is the answer then what is important here is that it is allowed to have a mismatch between what a shader expects/needs (shader X needs B, shader Y need C) and what is bound at a certain point during recording, just as long as you don't record an action command that causes the mismatched shader to be used.
Uniforms have two huge disadvantages over Storages. Veeery small size and no write access. Everyone tells this. I am looking for advantages of Uniforms more than month and still fail to find. Even here.
What is this binding parameter in the glsl shader?
Do you mean the binding declaration itself (e.g., binding = 0) or a specific parameter? If you mean the former, this is the way how things are bound in Vulkan: Resources are organized into sets of resource descriptors, and within a set, a specific resource descriptor is identified by a binding id.
The auto-translated subtitles of this video are misrecognized as German, which is a bit difficult for me as my native language is not English🥲, it would be perfect if this problem can be fixed🥰
this problem exists in most of videos of this series💦
Yeah, sorry that the subtitles aren't there yet. I'll try to add them during February.
Subtitles have been added to the first three episodes. Please let me know if it's better now!
Thanks, but this doesn't appear to be for beginner anymore. Suddenly from ep2 to 3 became so hard.
Oh really? Sorry to hear. We have to admit that we have received similar feedback already... maybe try to read up on some other beginner-level resources first (like those listed on the official Vulkan website: vulkan.org/learn#vulkan-tutorials) then come back to Episode 3.
What I do is I go between the link provided from cgtuwien and then back to this series to slowly see if there are any gaps that should be filled, since there's always something I might've missed or not understood yet.
I also use the resources provided from the beginning of the series which can be helpful :)
Vulkan is never meant to be beginner-friendly :D
You skipped episode 2?
Episode 2 is just delayed a bit (:
@@cgtuwien when is the eps 2?
@@thurfiann Episode 2 is now online: th-cam.com/video/nSzQcyQTtRY/w-d-xo.html