VULKAN PIPELINE
Also known as: Jaminal3D
Graphics 2 - Spring 2019
First of all, I have to thank Alexander Overvoorde for his e-book. Without it, we would never have known where to start. Also, a huge thank you to Sascha Willems, who has some incredible tutorials on his github. He's also super active when answering questions on different forums related to Vulkan, such as Reddit.
Vulkan is the Khronos Group's next API for graphics. Originally revealed in 2015 as "GL Next", its claim to fame is being a very verbose and low level API. A lot of things that might be automatically handled by the OpenGL API, now have to be explicitly stated when doing things in Vulkan. It offers more power, control, and cross-platform capabilities, at the cost of readability, and time spent creating it.
​
I personally worked on initial set-up, texture & model loading, validation layers, and the depth buffers. I worked with Josh to create the shaders we used, Semaphores, Command Buffers, Instancing, and Rendering.
I'm not really sure where to begin with Vk. I guess I'll start with a diagram that showed our understanding of Vk when we started writing our demo.
The thing I really like about Vk is that it has instances. You have to create a specific Vk instance, but then you can create other Vk instances for whatever you need. Want a specific instance that can only do certain render passes? You could do that, and swap out as necessary.
​
This diagram also really shows how verbose you have to be with Vk. There needs to be a structure that can talk with the graphics card. There needs to be a structure that holds render passes. There needs to be a structure that holds the entire graphics pipeline.
COMMAND BUFFERS
One of the things I really like about Vulkan are command buffers. You can record a list of commands into a command buffer, which can then be queued up, and sent off to the GPU. So, we just have to create the command buffer once, and not have to worry about submitting a bunch of commands every frame.
ASYNC BEHAVIOURS
I think I'm starting to write more than I need to, and I'm procrastinating on other work by writing this, so, I'll talk about the async things that Vk has, because they're really dope.
​
When drawing a frame, we need to do 3 things:
1. Get an image from the swap chain.
2. Execute the command buffer with that image to the frame buffer
3. Return that data to the swap chain, which lets us finally draw to our FSQ on the screen.
​
(The swap chain is basically a queue of frames to be rendered.)
Vk can do all of that asynchronously, and in any order. The problem becomes: what happens if things get out of sync? Corruption? Out of range exceptions? Weird things being rendered? To solve that, Vk gives us semaphores, and fences.
​
Semaphores synchronize operations across command queues. They will be automatically signaled by another semaphore. So, when another command finishes, this semaphore will be signaled that it's good to go.
​
Fences are slightly different. A fence must by explicitly signaled by the CPU. I.e, the programmer of the application has to tell a fence when it's ready or not, by a simple boolean switch.
​
So, for example, in drawing, we want to sync drawing, and presentation. Which means we can use semaphores. But, when submitting commands, which are cpu->gpu, we want to make sure we don't submit too many commands and overload the gpu. Therefore, we'd want to use fences there.
Concluding thoughts
There's a lot to unpack with Vulkan, and it's really cool stuff. But, there's no way in just one page I could hope to describe everything I want to.
​
Plus, this was a really good project that let me figure out a lot of graphics things I wasn't sure about. Like, how exactly does one get data to the GPU? Well, I was able to learn here.
​
Even though I can't understand everything that Vulkan is doing. I did learn a lot, and I want to keep playing with it when I can. Just so I can keep learning about a lot of these cool graphics things.
Extra Pictures
I'm adding some more pictures down here, because I'm super interested in Vulkan, and glad we were able to make something!
The demo running
Above shows it running with the console window open. We debug available extensions and debug layers.