<p>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.</p>
<p>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)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-08-23T11:16:49.957Z
2023-08-23T11:16:49.957Z
pmw1234
<p>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.</p>
<p>As I work through <a href="https://www.realtimerendering.com/" rel="nofollow noreferrer">Real-Time Rendering</a>, on my way to <a href="https://www.pbrt.org/" rel="nofollow noreferrer">Physically Based Rendering</a>, I want to create the foundations of a personal rendering platform so I can cement knowledge and get some experience. I just... <em>really don't want to do it in C++</em>. 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.</p>
<p>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++.</p>
<p>Is it possible to make the low-level syscalls (or write ASM for the syscalls) for Vulkan without using the LunarG C/C++ SDK?</p>

CC BY-SA 4.0
2023-08-23T07:58:45.567Z
What exactly do you hope to gain with making syscalls yourself over using language bindings?
Tare
<c++><vulkan><hardware>
Vulkan Syscalls
Sienna
# Vulkan Syscalls

(Asked by: username_0 on 2023-08-22)

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](https://www.realtimerendering.com/), on my way to [Physically Based Rendering](https://www.pbrt.org/), 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?

**Tags:** c++, vulkan, hardware

> **Comments:**
> **username_1**: What exactly do you hope to gain with making syscalls yourself over using language bindings?  

---

## 1 answers

### Answer by username_2 on 2023-08-23. Score: 0

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.


---

