Racket-Vulkan: Contributor Content, CLI, and Flexible Code Generation
racket-vulkan
is evolving in pretty exciting ways, and more oppurtunities are
popping up to improve it than I can handle alone. I should start with
a blanket thank you to the volunteers who A) offered use of their
systems, B) opened PRs, or C) simply told me how excited they were
about the project.
I added contributor documentation to show the techno-operational needs of the project and current priorities. The single biggest need is additional Vulkan applications. I’m still in the process of porting code from vulkan-tutorial.com to render a triangle using GLFW. At least with that, enough evidence will exist to show support for presentation with swap chains and compute pipelines. So cool!
Another key development is a new CLI called ravk
. That’s short
for racket-vulkan
, and is pronounced “Ravick” (to sound a
little like “Havoc”). ravk
exposes a pluggable Racket
code generation machine and a Vulkan specification manager
to the end user. Why is this great? Because if the
racket-vulkan
source code ends up out of date, you can
still use it to generate up to date Vulkan bindings. In other
projects I’ve seen, if language bindings for Vulkan are out of date,
then users depend on a maintainer to fix that. With my approach, users
don’t have to wait on me if I’m focused on something else.
The “pluggable code generation machine” is nothing more than a collection of specialized Racket modules that take a Vulkan specification and generate a small selection of code against assumptions it is free to make. This is important because Vulkan specifications evolve organically, and even backwards-compatible changes might force you to reassess an approach. Doing so was hellishly difficult with a monolithic code generator.
Finally, I’ve submitted the porject to the Racket Game Jam. It’s not an actual game, but I need feedback whenever I can get it.
Some future developments include continuous integration, a stable set
of bindings, opt-in type safety and convenience functions, a
#lang
s for system requirements, and a shader #lang
to
produce SPIR-V modules. That’s a LOT of work, but this is the kind of
project where that doesn’t feel intimidating.
If you are interested in following or supporting the project, please watch it on Github. I’m shifting gears to focus on maintainability and stability, and then new features will come.