readme

This is a Vulkan binding generated from vk.xml. This generator is written from scratch, including the xml parser. Tested on Vulkan 1.4 and jai version beta 0.2.017.

This has no relation to osor_io’s Vulkan jai binding, osor_vulkan.

The primary reason for me to write this binding is because the above binding does not compile anymore.

I have generated a set of binding code in the repo. I don’t recommend directly using them. They are just for reference. You should generate your own using the following instructions.

Usage

Obtain a vk.xml. I recommend to get it from your installation of Vulkan SDK, if you are on a mac and using homebrew, the binding is located at /opt/homebrew/share/vulkan/registry/vk.xml. If you are on Linux, it is usually at /usr/share/vulkan/registry/vk.xml.

Obtain a video.xml, which should locate at the same directory of vk.xml.

You can either modify the VK_XML_PATH variable in the top of generate.jai or you copy the vk.xml to the current directory. Same for generate_video.jai.

Run. The execution time should be pretty fast, it is sub 1.2s on M1 chips, and sub 1.6s on 9950x3d. (Yes, 9950x3d is slower…) The time needed for video.xml is negligible. Most of the time is spent on my naive xml parser, I may write a better one in the future.

jai generate.jai
jai generate_video.jai

video.xml is parsed separately because it is unlikely to change like vk.xml. But both of them is necessary to generate because vk.xml depends on video.xml.

Clone the directory to the modules of your project, change the directory name to Vulkan. You should be able to include it by something like this.

#import "Vulkan";

Difference between stock Vulkan binding

There is a stock Vulkan binding comes with the Jai compiler. However, that binding is really outdated. And that binding was generated by parsing vulkan.h and linking libvulkan.so.

For someone who want a dynamic loader, it sucks.

I tried to steal the binding from Odin vendor library. That route was a lot easier and work perfectly. But generating a binding from scratch means that we no longer need to depends on Ginger Bill to update.

Roadmap

I planned to add a switch to strip the vk prefix, but have not implemented it yet. Also, stripping vk prefix means that any thing depends on Vulkan also need to strip the vk prefix, like Vulkan Memory Allocator.

Currently there is a variable in generate.jai named STRIP_VULKAN_PREFIX, it does nothing at the moment.

If you want to link the vulkan shared library instead, you may set the DYNAMIC_LOADER to false, but you have to link it yourself in your build.jai. I do not provide any linking in the generated module.jai.

Most of the vendor dependent libraries definition is hardcoded by hand. I may write a function to generate them instead. But because the size of them is still manageable by human. I don’t bother to deal with it at the moment.