Index and Staging Buffers - Vulkan Game Engine Tutorial 16

[@alexanderdorenkamp]

I can't stop working through this series! SO AWESOME!

[@BrendanGalea]

Glad to hear it! More videos on the way soon!

[@user-dh8oi2mk4f]

1:09 That's the best explanation of an index buffer I've ever heard.

[@BrendanGalea]

Thank you!

[@BrendanGalea]

Note at 02:50 I declare a struct named Builder to store the model vertex and index information to then use to construct the model. In hindsight, this probably could have been called something like Data to avoid confusion with the "Builder" programming pattern. And at 3:26 I add the createIndexBuffers function, when a better name for it would be createIndexBuffer (since a model can only use a single index buffer)

[@supesu879]

Amazing content keep it up!

[@SkullJakob]

Great video! I’ve also enjoy your resources you link to, and started reading Game Engine Architecture by Jason Gregory after your last video

[@vcihiethea]

9:37 When you rotate the cube, in yours the cube seems to be rotating around one of it's indices, while in mine it's rotating around the camera.

[@euclidentity1106]

Amazing Videos !

[@rutvikpanchal5726]

Awesome video

[@NisalDilshan]

Good Content!🤩

[@redsteph]

As always I'm looking forward for the next video! I have few questions: Are you planning on implementing a lightning system, collisions (rigid bodies), skeletal animations and mouse input? Thank you very much :D

[@BrendanGalea]

Yup eventually! Next tutorials will be on loading 3D models, diffuse lighting and specular lighting

[@carterthaxton]

At 2:09, it should be index buffer = {0, 1, 2, 1, 3, 2} to match the diagram above. Alternatively, the diagram above could be labeled v0, v2/v3, v1/v4, v5.

[@gvcallen]

Yoh, awesome tutorial. Just wondering, is there any way to avoid the memory allocation for the staging buffer on the host side i.e. the void* data? My thought process is that we have already allocated memory for this inside the std::vector, and so we are allocated more memory when maybe not neccessary. If not, would a better design pattern potentially be to "request memory" from the LveModel class which in turn maps memory and returns the data? This way only one allocation is made? Thanks a lot !

[@BrendanGalea]

Ya I think that could make for a cool optimization to the LveModel::Builder object. Make it so that the builder manages the staging buffers and I think you could create a custom allocator for the vector of vertices and indices that use the staging buffer mapped memory region instead of allocating their own. So you avoid having to duplicate the memory Host side, as well as avoid the copy from the vector to staging buffer memory region. And if you re-use the builder object you can just overwite that staging buffer memory region and avoid an extra memory allocation. Might not be worth the effort at this stage, but its definitely an idea worth keeping in the back of your mind!

[@gvcallen]

awesome thanks for the reply!

[@avatharbehemoth]

@ 11:00 at vulkan tutorial they use a hash function to get rid of duplicate vertexpoints and vertices. which is a fine way to reduce the count. a manually created index list seems harder to make, or do modelbuilders do that for you? i guess there is software to make models.

[@BrendanGalea]

We’re doing the same method as vulkan tutorial. We build the index list and as we do so we filter out the duplicate vertices using the hash function

[@bubbango]

Hi! When you were talking about staging buffers it hit my mind that I don't fully understand how the process of displaying the object and moving around is done. What I understand is that vertices and indices to be used are always in the GPU's VRAM, and this data doesn't change (for now). And in order to process that data we need a graphics pipeline, which consists of 5 steps, mainly. Two of these steps are vertex shader and fragment shader, which are both a .vert and .frag programs compiled. So does the compiled program get uploaded into the GPU's VRAM in order to execute it or it's located in the main RAM, where the CPU processes vertices and fragments? In a similar way, when we use vkCmdPushConstants to push the rotation and translation matrices, does this data get processed by the GPU or the CPU? I hope I am making sense 😅 And thank you for these incredible tutorials :)

[@BrendanGalea]

"where the CPU processes vertices and fragments?" It's definitely the GPU doing the processing of vertices and fragments, and execution of the pipeline stages (shown in tutorial 2 with that purple green image) is all occuring on the gpu "which consists of 5 steps, mainly" Yup the 5 stages I simplified to are a good mental model for when getting started, and were pretty much the only stages initial gpus had. There are a couple more that most modern devices have such as geometry shaders and tesselation, which vulkan-tutorial.com/Drawing_a_triangle/Graphics_pipeline_basics/Introduction explains in more detail than I have in my videos so far. "What I understand is that vertices and indices to be used are always in the GPU's VRAM, and this data doesn't change (for now). And in order to process that data we need a graphics pipeline, which consists of 5 steps, mainly. Two of these steps are vertex shader and fragment shader, which are both a .vert and .frag programs compiled." Yes this is an excellent summary of what we're currently doing! It is possible when creating the buffer objects to use different types of memory based on the memory property flags. But I'm pretty sure any memory a shader program accesses must be on the GPU. So the GPU can't acess CPU RAM, but the CPU does have access to at least some of GPU RAM, and the amount will differ by device. One thread to pull on might be this extension (supported only by AMD and Nvidia devices supposedly www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_memory_budget.html) "So does the compiled program get uploaded into the GPU's VRAM in order to execute it or it's located in the main RAM, where the CPU processes vertices and fragments?" Such a great question and something I actually have never thought about. I would presume that the answer is yes, when we call vkCreateGraphicsPipelines the createInfo has the shader data and part of that process would be moving the compiled shader data to the GPU VRAM. But maybe this isn't always true!! I read one reddit post that was saying for openGL that it could be device and driver dependent whether a shader is stored in cpu or gpu memory. But something someone posted on the internet is a pretty terrible source 😆 And this also contradicts other things I've read that the GPU doesn't have access to CPU RAM.... So this is something I'd like to research more when I have the chance. Being in gpu memory makes more sense from a performance perspective, but maybe its actually only when you bind the pipeline it would transfer the memory, I'm not sure but it raises a lot of questions. That might also explain why its recommended to limit binding pipelines, because if a bind causes a memory transfer of the shader from CPU to GPU memory it makes sense that it would be a somewhat expensive operation. (eg if game objects A and C use pipeline1 and gameobject B uses pipeline2 then your engine should do bind pipeline 1 render A render c bind pipline 2 render B and should avoid bind pipeline 1 render A bind pipeline 2 render B bind pipeline 1 render C If you do look into this please let me know what you find!! And I'm glad you're enjoying the tutorials so far 😊 This ended up being a way longer answer than I intended, I got carried away. You're definitely on the right track if these are the type of questions you're asking.

[@bubbango]

@@BrendanGalea Thank you very moch for the detailed answer. I really appreciate it. If I find something I'll reply to this comment :)

[@anishdeshpande2363]

Hello Brendan Galea, can you please make a tutorial on how to build for Android, because Vulkan is platform independent but there is absolutely no tutorial on the internet for developing for atleast a very common platform like android

[@BrendanGalea]

This is a great suggestion! I'll add it to my list of possible tutorials. I actually haven't tried using vulkan on Android yet. We'd also have to not use glfw I believe. So it may be a bit of time before I get to this, I think I'd like to cover all the basics first. But thanks! Also I believe the github.com/SaschaWillems/Vulkan examples are built to run on android as well. So maybe that's a good starting point to find an example of how it can be done.

[@anishdeshpande2363]

Thank you very much, the basics provided by you are itself very hard to find, I really appreciate your tutorials

[@yaircambordamorocho4506]

Uniform buffers are coming?

[@BrendanGalea]

yup pretty soon. We've got loading models, diffuse shading and specular lighting to cover first. So tutorial 20 will start on uniform buffers. So we should be there in about a month.

[@RadoslavRalev]

LLBG - Long live Brendan Galea!

[@BrendanGalea]

lets not jinx things :P