Starting to experiment with Vulkan

So, it's a simple story -- boy meets API, yada, yada, yada...

I've started to build some initial experiments with the Vulkan API. Version 1.0 of the API was just released -- and there's an SDK from Valve (called LunarG) around.

Initial impressions

My first impressions are very positive! Many of the design ideals and structures of the API are familiar from my days working with consoles (particularly the Sony consoles). This type of API has not been available on open platforms (like Windows) before -- so for people who don't have experience with consoles, it might give an idea of what it's like.

I'm also really happy how much of the surrounding resources have been made open-source... The samples, shader compilation tool-chain, etc... It's all very effective use of github.

Khronos have drawn attention to how much input they've gotten from the game engine development community. And it shows in the results. This is the kind of API that an experienced engine developer wants to see.

I think it's also a model that is much more viable for cross platform development than anything we've seen before. OpenGL had a lot of problems, and DirectX was so tied to the Windows platform. But this feels like something that is truly viable across many platforms (including low end and high end).

I'm really impressed with how a third party group has managed to build an API that balances the needs of engine developers with the needs of hardware designers. I think Khronos has really shown how this kind of thing should be done -- and it seems like a good model for other APIs (sound, physics hardware, etc).

Long term viability

Vulkan feels like an API that could stick around for awhile. OpenGL has been on it's last legs for a long time... And DirectX always needs constant refreshes to survive. But Vulkan feels like it will be here for awhile. Due to it's cross-platform and long term viability, it's really undermined DirectX and Apple's Metal.

I felt the same about C++11, when I started using it. The new C++14 is a huge step forward from the old C++98 days. Many of the design patterns we C++ programmers always wanted to use are not much more viable in C++14. Stroustrup said that C++14 "completes" C++11 -- but really, I think it "completes" C++ as a whole.

C++17, C++20 -- these are going to be even better, also. And Vulkan will get better over time. But my gut feeling is that code written in C++14 and Vulkan 1.0 is likely to be viable for a very long time.

By comparison, code written in OpenGL, Apple's Metal (or, help us, DirectX9) is going to feel stale pretty quickly.

The unfinished part of the equation is the shader language. Vulkan uses SPIR-V as an intermediate language... And that's great. But it's not clear yet what high level language should be used. The current SDK uses GLSL -- but maybe we could do better? Perhaps C++ is an option here... But maybe we would be better off with some next iteration forward from HLSL and GLSL.

But it's not easy!

Clearly, Vulkan is not intended as a beginner's API. DirectX always tried to find a balance between power and accessibility for it's API. But Vulkan is designed by and for experienced developers.

This is clearest in the threading and reference counting approaches. Vulkan is mostly leaving it up to the engine developer to handle these things. That's great when you want to write a really efficient engine... But it's going to be a major hassle for first timers.

XLE code

You can see the Vulkan code in the "experimental" branch.

I will be adapting and improving platform abstraction layer in XLE as I plug in Vulkan features. Fortunately, it seems that the XLE architecture should mostly work well with Vulkan.

I will also try to use HLSL with Vulkan by cross-compiling first to GLSL and then to SPIR-V.