Vulkan Syscalls

Question

I'm working on educating myself more about computer graphics, and the more I learn and play with the technology, the more I get frustrated by the dependencies on C++ (even though I know why it exists). I've built prototype renderers with Vulkan in C# and Go using language-specific bindings to understand the general process. I really enjoy Vulkan and I feel like it's both a good time to learn graphics development and also a great low-level graphics platform.

As I work through Real-Time Rendering, on my way to Physically Based Rendering, I want to create the foundations of a personal rendering platform so I can cement knowledge and get some experience. I just... really don't want to do it in C++. I know that Vulkan is an API specification (and ecosystem) for the low-level hardware drivers by NVIDIA/Intel/AMD/others, but that's about it.

I want to evaluate the possibility of writing a non-C++-based Vulkan driver using native syscalls so I don't have to deal with the C++ ecosystem. I would like to assume the OS would pass along the Vulkan syscalls to the hardware drivers, and they would be executed from there, but I'm not really sure. I feel like it's possible, and likely extremely tedious and time-consuming, but it might be worth it if it means I don't have to work entirely in C++.

Is it possible to make the low-level syscalls (or write ASM for the syscalls) for Vulkan without using the LunarG C/C++ SDK?

Answer 1

If you want to play with making the calls directly in assembly then write a program in c or C++ (debug it to life) then run it through the disassembler and you be able to find the calls in the assembly language that is output. There will usually be additional code that takes the input of your code and preps for the actual system call. Also, there will be functions that don't do any calls at all.

I recommend keeping the code as short as possible or even just writing a function that does the call and disassemble that function. This is an excellent tool for various debugging work. ( it is over used in the name of performance)

I highly recommend doing at least this first step. An excellent method of evaluating functions is to disassemble two similar functions and compare the assembly code.

Also, this is a good exercise for anyone to go through and most folks gain a whole new appreciation for high level languages once they have written a few simple assembly level programs. Assembly isn't the panacea it was once thought of.

For most graphics API's at least some portion is written for and executes in user space without actually doing any system calls, or only doing the call after a fair bit of work in the user address space. So some calls may not have a system call in them at all.

If the goal is to capture the calls and then write another language interface around them, then capturing all the setup, and any work that is done after the call will be necessary as well. And frankly there are better methods.

Also there will likely be calls down into the operating system that are unrelated to the API but which are, again, setting up for the API call. You will need to be able to filter/understand and recreate these calls before making an actual call.

Finally, the last I heard, it is the c interface that is the more popular interface for Vulkan not the C++ interface (although most developers are writing programs in C++ and using the c interface). You may want to consider working in the c language.