I really want to thank you for making these lectures publicly available. Vulkan is a complex API, but you did a great job of breaking it down into logical components that make it easy to understand. Also, the diagrams and accompanying animations were extremely helpful for visualizing the flow of information throughout the graphics pipeline.
Wow, you are gifted to communicate complex subjects. There is almost no comprehensible resource available to explain synchronization in Vulkan, you just nailed it. THANKS!
Dear Mr. Johannes Unterguggenberger, I would like to extend my sincere appreciation for the outstanding masterpiece you have created in your CZcams video on Synchronization in Vulkan. Your concise yet highly illuminating explanations, coupled with fantastic animation examples, showcase your exceptional expertise in the field. Thank you immensely for generously sharing your outstanding knowledge of Vulkan with the community.
I've been looking for comprehensive explanations of these topics a lot now and finally found this video that has it all. Very well done, Mr. Unterguggenberger :)
Having watched all 7 episodes I must say this wat the best explanation I've seen so far. Kudos to Johannes for such quality work! Fortunately, the examples are great and nicely visualized. I'm wondering how great it would be to see a book published with such quality.
Hey! Just wanted to say thank you for taking the time to visualize what the specification is talking about. I've been looking for something like this for a long time, and I finally found it!
sweet! I'm updating my notes :) I can't say I understand the Spec's descriptions, but with a simplified explanation and visual example it's really easy to understand Vulkan. And I agree with your initial comment. Once one understands synchronization primitives and their use cases...that's like a large part of Vulkan there. The rest is somewhat straightforward.
I have viewed this twice now and i found a little trick helpful for me. I kept on getting confused with reading the pipeline and memory access barriers. If you mentally say "wait for prior commands (srcStage), at my (dstStage)" it might make this more clear for you. The "my" part is taking the stage right after the pipeline barrier as the stage of interest or focus. The "at" part only really applies if the command after the pipeline barrier reaches its stage it needs to wait at early. I don't know if this is technically accurate or works with everything but it has helped me so far.
As I understand it, work submitted on a queue doesn't even have to start in order. When the spec says work "respects submission order", this only means that the order you call Vulkan functions can be used as meaningful reference points for your synchronization commands and some *very* limited implicit synchronization. Without that statement, there'd be no meaningful ordering you could actually reference in synchronization commands to establish custom synchronization. But if you don't record any synchronization commands within a command buffer, the driver essentially has *no* implicit ordering whatsoever and has free-reign to do whatever it wants. The only things the spec is really insistent on providing any meaningful ordering within a command buffer are render passes' fragment/blending+logic+color operations for a given (x,y,layer,sample), and image layout transitions.
However, *batches* in a queue submission *are* said to start in the order submitted. So it seems commands in a batch can be arbitrarily reordered, but the batch itself can be considered to "start" earlier.
Thanks for your message. Under 7.2. Implicit Synchronization Guarantees, the spec says that the order is meaningful -- but your point is that the commands do not have to be started in submission order in any case, just because it is meaningful. Is that right?
@@cgtuwien No problem. :) And yeah, exactly. Submission order is meaningful in the sense that mainly barriers rely on it for establishing their scopes, as well as some very narrowly-scoped implicit ordering guarantees (like framebuffer operations in a particular render pass). But for the most part it doesn't actually impact when work begins or ends.
@@thefriendsofmrgyro6361 These are valid stage flags (see VkPipelineStageFlagBits2 in the specification) and access flags (see VkAccessFlagBits2 in the specification). The combination of VK_PIPELINE_STAGE_2_FRAGMENT_SHADER_BIT and VK_ACCESS_2_SHADER_READ_BIT is valid too as per Table 4 of the specification. I can't see any error or typo on slide 118.
I really want to thank you for making these lectures publicly available. Vulkan is a complex API, but you did a great job of breaking it down into logical components that make it easy to understand. Also, the diagrams and accompanying animations were extremely helpful for visualizing the flow of information throughout the graphics pipeline.
Wow, you are gifted to communicate complex subjects. There is almost no comprehensible resource available to explain synchronization in Vulkan, you just nailed it. THANKS!
Dear Mr. Johannes Unterguggenberger,
I would like to extend my sincere appreciation for the outstanding masterpiece you have created in your CZcams video on Synchronization in Vulkan. Your concise yet highly illuminating explanations, coupled with fantastic animation examples, showcase your exceptional expertise in the field. Thank you immensely for generously sharing your outstanding knowledge of Vulkan with the community.
Your work is invaluable, thank you so very much!
I've been looking for comprehensive explanations of these topics a lot now and finally found this video that has it all. Very well done, Mr. Unterguggenberger :)
Having watched all 7 episodes I must say this wat the best explanation I've seen so far. Kudos to Johannes for such quality work!
Fortunately, the examples are great and nicely visualized.
I'm wondering how great it would be to see a book published with such quality.
Thank you for this. I’ve been waiting for the synchronisation episode!
Hey! Just wanted to say thank you for taking the time to visualize what the specification is talking about. I've been looking for something like this for a long time, and I finally found it!
sweet! I'm updating my notes :)
I can't say I understand the Spec's descriptions, but with a simplified explanation and visual example it's really easy to understand Vulkan.
And I agree with your initial comment. Once one understands synchronization primitives and their use cases...that's like a large part of Vulkan there. The rest is somewhat straightforward.
What a great lecture/series; thank you Johannes!
Great quality lecture! Thank you.
Really impressive. He focuses on just the right issues.
I have viewed this twice now and i found a little trick helpful for me. I kept on getting confused with reading the pipeline and memory access barriers. If you mentally say "wait for prior commands (srcStage), at my (dstStage)" it might make this more clear for you. The "my" part is taking the stage right after the pipeline barrier as the stage of interest or focus. The "at" part only really applies if the command after the pipeline barrier reaches its stage it needs to wait at early. I don't know if this is technically accurate or works with everything but it has helped me so far.
Welcome back 👏👏
👋😎
woohoo! great vkContent ✅
Great lecture!
I finally know what is a barrier and how to use them.
As I understand it, work submitted on a queue doesn't even have to start in order. When the spec says work "respects submission order", this only means that the order you call Vulkan functions can be used as meaningful reference points for your synchronization commands and some *very* limited implicit synchronization. Without that statement, there'd be no meaningful ordering you could actually reference in synchronization commands to establish custom synchronization. But if you don't record any synchronization commands within a command buffer, the driver essentially has *no* implicit ordering whatsoever and has free-reign to do whatever it wants.
The only things the spec is really insistent on providing any meaningful ordering within a command buffer are render passes' fragment/blending+logic+color operations for a given (x,y,layer,sample), and image layout transitions.
However, *batches* in a queue submission *are* said to start in the order submitted. So it seems commands in a batch can be arbitrarily reordered, but the batch itself can be considered to "start" earlier.
Thanks for your message. Under 7.2. Implicit Synchronization Guarantees, the spec says that the order is meaningful -- but your point is that the commands do not have to be started in submission order in any case, just because it is meaningful. Is that right?
@@cgtuwien No problem. :) And yeah, exactly. Submission order is meaningful in the sense that mainly barriers rely on it for establishing their scopes, as well as some very narrowly-scoped implicit ordering guarantees (like framebuffer operations in a particular render pass). But for the most part it doesn't actually impact when work begins or ends.
fix page 118 of your notes!
Would you be so kind to point out what's wrong in your opinion?
@@johannesugb Top left corner ": VK_PIPELINE_STAGE_2" followed by whatever that is, "VK_ACCESS_2_" followed by whatever that is
@@thefriendsofmrgyro6361 These are valid stage flags (see VkPipelineStageFlagBits2 in the specification) and access flags (see VkAccessFlagBits2 in the specification). The combination of VK_PIPELINE_STAGE_2_FRAGMENT_SHADER_BIT and VK_ACCESS_2_SHADER_READ_BIT is valid too as per Table 4 of the specification. I can't see any error or typo on slide 118.
@@johannesugb I am looking at the pdf from the link you've provided. The two lines on the top left of page 118 are unreadable after halfway.
@@thefriendsofmrgyro6361 Ah, the slides. ^^ Have been updated.