Vulkan-Renderer¶
Inexor is a MIT-licensed open-source project which develops a new 3D octree game engine by combining modern C++ with Vulkan API.
Documentation¶
Quickstart: Building Instructions (Windows/Linux) & Getting started
- Development
- Source Code
- How to contribute
- Frequently asked questions
- What is Inexor?
- Which platforms are supported?
- What is the current state of the project?
- How is Inexor organized?
- How to contact us?
- How to build?
- Where to find Inexor’s documentation?
- What is Vulkan API?
- Why is Vulkan API the future?
- Can you explain Vulkan API in simple terms?
- How difficult is development with Vulkan API?
- Does my graphics card support Vulkan API?
- Will you support other rendering APIs?
- Which topics are currently not in focus of development?
- Changelog
- Helpful Links
- Source Code License
- Contact us
Frequently asked questions¶
Please visit inexor.org and join our Discord server.
What is Inexor?¶

Inexor is a MIT-licensed open-source project which develops a new 3D octree game engine by combining modern C++ with Vulkan Vulkan API.
We have the following goals for the Inexor engine:
Combine modern C++ with Vulkan API.
Task-based parallelization using a threadpool and a work stealing queue.
Create a Vulkan API codebase which can be used in production.
We are using good software engineering practices:
Code design by strict compliance with the C++ core guidelines and Scott Meyers books.
Use of the new C++ standard library (C++11, C++14, and C++17).
Code documentation using doxygen.
Automatic unit testing and benchmarking.
CMake project setup.
You can find Vulkan example code online which follows the mantra “don’t use this in production - it’s tutorial code”. Inexor disagrees with this as we believe that defeats its own purpose. If example code is not meant to be used in some other projects then there’s something wrong with that example code. Many projects don’t use a proper memory management library like VMA or they do not abstract their code using RAII, but use a lot of code duplication instead. Inexor is designed to be used in production. Bear in mind however that Inexor is also still far away from being a finished game engine.
Which platforms are supported?¶
We support x64 Microsoft Windows 8, 8.1, and 10.
We support every x64 Linux distribution for which Vulkan drivers exist.
We have specific build instructions for Gentoo and Ubuntu. If you have found a way to set it up for other Linux distributions, please open a pull request and let us know!
We do not support macOS or iOS because it would require us to use MoltenVK to get Vulkan running on Mac OS. Additionally, this would require some changes in the engines as not all of Inexor’s dependencies are available on macOS or iOS.
We also do not support Android because this would require some changes in the engines as not all of Inexor’s dependencies are available on Android.
What is the current state of the project?¶
We are still in very early development, but this project can already offer:
A modern C++20 codebase with CMake setup.
Stable builds for Windows and Linux using Continuous Integration (CI).
A rendergraph in early development.
ImGui integration using separate renderpasses.
RAII wrappers for various Vulkan resources.
Extensive logging with spdlog.
Vulkan Memory Allocator for graphics memory management.
VMA memory replays for debugging are already working.
Full RenderDoc integration with internal resource naming.
How is Inexor organized?¶
Inexor has no central authority.
It’s a headless collective which makes decisions through creative discussions.
We are welcoming new contributors to our team.
How to contact us?¶
Please visit inexor.org and join our Discord server.
How to build?¶
If you have any trouble building please open a ticket or join our Discord.
Where to find Inexor’s documentation?¶
Read our docs here.
What is Vulkan API?¶

Inexor uses Vulkan API as rendering backend. Vulkan is a new, multi platform low level API (application programming interface) for high-performance graphics programming and computing. It is the successor to OpenGL, and it is important to state that is is very different from it. Vulkan is not just a new version of OpenGL or an extension of it. Instead, Vulkan is a very low level API which allows for much deeper control over the graphics card and the driver, like DirectX 12 or Apple’s Metal. Unlike OpenGL, Vulkan API is build in a way it fits the architecture of modern graphics cards. This offers better performance due to reduction of overhead and driver guesswork during runtime. This results in higher frame rate, more predictable CPU workload and a lower memory usage. The most important benefit of Vulkan is the fact that it allows for multithreaded rendering, which is not possible in OpenGL at all. In general, Vulkan does a lot of work during the initialization of the application but therefore reduces work during rendering. Since Vulkan is much more explicit in terms of code, it foces you to think about the structure and architecture of your code. Both Vulkan and OpenGL are being developed by the Khronos Group. Vulkan is being developed through an unprecedented collaboration of major industry-leading companies (Google, Intel, AMD, NVidia, Sony, Samsung, Huawei, Qualcomm, Valve Software and many more). Vulkan is the only multi platform low level graphics API.
Why is Vulkan API the future?¶
Performance
Lower and more predictable CPU load which results in better performance and a reduction of driver guesswork.
Vulkan API is asynchronous and encourages multithreaded rendering. This is not possible with OpenGL!
The low level API design of Vulkan allows for advanced optimizations such as rendergraphs for generic rendering architectures.
It also wants you to use the GPU asynchronously, sometimes referred to as GPU multithreading.
Vulkan allows the use of multiple GPUs, even if they are not physically linked via crossfire bridge.
The reduction of CPU workload and it’s improved predictability can enforce the GPU to be the limiting factor of performance, as it should be.
Memory efficiency
Vulkan gives much deeper control and better interfaces over graphics and system memory.
Vulkan API enforces memory management to be done by the application rather than the driver.
Since the application knows best about the importance of every resource it uses, Vulkan API allows for a better memory usage.
Architecture
Unlike OpenGL, Vulkan fits the design of modern GPUs as it is not just one single state machine. This means Vulkan API was designed from the beginning to match the architecture of modern graphics cards. OpenGL however still matches the design of graphics cards from the time it was invented in the 1990s.
Vulkan is a fresh start, whereas OpenGL contains a myriad of hacks to support very rare use cases.
Vulkan has layers and extensions as part of its design. You can check for supported GPU plugins on the target machine and enable them as needed.
Vulkan API itself is completely platform agnostic.
Available on a variety of platforms: Windows, Linux, mobile devices and much more!
The ending of the OpenGL era has begun.
Vulkan is being developed through an unprecedented collaboration of major industry-leading companies. It is not being developed by one company only (like Microsoft’s DirectX for example).
As Vulkan’s motto states, it really is industry-forged.
Consistency and standardization
Vulkan precompiles shaders to a standardized bytecode format called SPIR-V. This also reduces driver guesswork during runtime.
The explicit design of Vulkan gives much deeper control and avoids driver guesswork and undefined behavior of graphics drivers.
Debugging tools
Validation layers and diagnostics can be independently activated during development, allowing better error handling and debugging compared with OpenGL or DirectX.
Upon release builds, the validation layers can be turned off easily.
Vulkan API applications can be debugged with RenderDoc.
The Vulkan specification is very easy to read and it is the central guideline for how to use the API.
Open Source
Vulkan API and some Vulkan graphics card drivers are open source.
Can you explain Vulkan API in simple terms?¶
Vulkan API gives programmers much deeper control over the gamer’s hardware.
If applied correctly, Vulkan can result in a significant performance boost.
The API encourages the programmers to think in detail about graphics cards and their game engine.
It offers advanced optimization techniques which can result in a lower RAM and video memory usage.
Using Vulkan can yield in lower and more predictable CPU usage.
Vulkan allows programmers to make more effective use of multiple CPU cores.
How difficult is development with Vulkan API?¶
This API does a lot of initialization during the loading phase of the application.
The key to success is a good abstraction of Vulkan API based on the needs of the application/game.
Vulkan is a C-style API. In simplified terms you fill out structures which start with
Vk..
and submit them together with other parameters tovk...
functions. That’s it. No complex interfaces.Vulkan API has a very good documentation.
The challenges of Vulkan game/engine development boil down to basic programming challenges: abstraction, resource management and parallelization.
You may want to read Vulkan in 30 minutes by Baldur Karlsson.
Does my graphics card support Vulkan API?¶
You can look up your graphics card in the Vulkan hardware database by Sascha Willems.
Every new graphics card which is coming out these days supports Vulkan API.
Vulkan is also supported on older graphics cards going back to Radeon HD 7000 series and Nvidia Geforce 6 series.
Will you support other rendering APIs?¶
No, because testing for Vulkan already takes a lot of time and there is no sense in supporting deprecated technology.
Some studios like id-software also dropped OpenGL entirely.
Vulkan API is the only low level multi platform graphics and compute API.
Which topics are currently not in focus of development?¶
We are currently focusing on the renderer and Vulkan API. When the time has come, we will take parallelization into account.
A game engine needs other components besides rendering of course. However, we are currently not focusing on the following topics: networking, sound, physics, packaging of game engine resources and everything else which is not related to rendering.
We will not begin to support additional platforms besides Linux and Windows in the near future.