Hello Vulkan

Entry posted by Josh · April 26, 2019

2,472 views

Two days and 823 lines of code later, I present to you the Vulkan triangle of awesomeness, running in our engine:

Here are my thoughts on Vulkan:

It's ridiculously verbose. You have to specify every little detail of the rasterizer, there's a million classes to create, and every little variable has to be exactly right. There's really no reason for this because 90% of the code is just something you copy and paste.

Shaders can use GLSL, which seems very weird, but it makes things easier for us. The GLSL validate tool is used to precompile shaders into SPIR-V code, which works across all hardware, which is very nice. This means that shader code can finally be made closed-source, if you want to. Shaders are compiled into binary .spv files.

After walking through the steps of setting rendering up in Vulkan, it is more clear to me what is going on under the hood inside the graphics drivers for OpenGL.

I tried running the app on both Nvidia and Intel graphics, and got the same exact results each time. Vulkan should provide more consistent results across different vendor hardware, and might not require cross-hardware testing. That's a big plus.

Khronos could have easily supplied a middle layer of C++ code to standardize this. The fact you have to look up all this stuff on a bunch of github repositories and third-party tutorials is awful. It pretty much guarantees that everyone who uses Vulkan is going to do it through a commercial game engine like ours.

You can download my test application here:

vktest.zip

The application will display a lot of errors when you close the window because resources are not being freed correctly yet.
The program will probably crash if you resize or maximize the window because this has not been accounted for yet.

I think it is still a big challenge to build a full Vulkan renderer that was doing everything our OpenGL renderer was doing, but the fact that we can reuse all our GLSL code helps a lot. Stay tuned!