Vulkan rendering backend
AFCMS opened this issue · comments
Currently Minetest only support OpenGL and OpenGL ES.
These are many things Minetest would benefits from a Vulkan rendering backend:
- Vulkan has a better support of modern hardware, with notable improvements of multithreading support
- Vulkan extentions exists for things like cross vendor hardware raytracing which may be useful for graphical improvements in the future
- MacOS etc deprecated OpenGL in favor of Metal starting from 10.14 (2018). Vulkan SDK includes MoltenVK, which is a Vulkan implementation on top of Metal API, allowing Minetest to use the maintained MacOS graphical API.
- Vulkan unified OpenGL and OpenGL ES, so Android rendering will be made easier for long term (85% of Android marketshare already have Vulkan support). Vulkan apps can also sightly improve battery life on mobile devices.
- Vulkan's design is better suited for VRR, at least on linux
- EDIT: Vulkan can also select the dedicated GPU itself (instead of using prime-run on hybrid laptops for exemple)
Links:
I just want to mention that there's also webgpu (spec draft: https://gpuweb.github.io/gpuweb/, implementation: https://github.com/gfx-rs/wgpu-native), which despite of its name can also be used out of the web.
- From my experience, it wraps vulkan in a way that makes using it still feel similar to vulkan, but without all the verbosity, which makes it really nice to use.
- Implementations also supports multiple backends, e.g. opengl es 3 (see https://docs.rs/wgpu/0.18.0/wgpu/enum.Backend.html).
- And due to its input validation, we could, in the far future, allow mods to use it almost directly, and let them provide shaders.
No way in the foreseeable future. It’d be enormous work for dubious gain.
Also, you can run OpenGL atop of Vulkan or Metal (but not vice-versa).
Some work already have been done to give a Vulkan backend to upstream irrlicht: https://irrlicht.sourceforge.io/forum/viewtopic.php?t=52371
IrrlichtBAW (now Nabla) have a Vulkan backend: https://github.com/Devsh-Graphics-Programming/Nabla
Maybe nobody have the time right now to try building a Vulkan backend, but Vulkan is the successor of OpenGL, with reworked concepts for 25y of GPU evolutions. Many serious game / game engines support or moved entirely to Vulkan: 0AD have an experimental Vulkan backend, Godot, Unreal Engine enable Vulkan by defaut, Source 2 based games uses Vulkan under Linux, all windows games running with Proton use Vulkan, etc.
Vulkan is definitely something to think about for the future.
You must be new here. Minetest uses OpenGL 2.0. And OpenGL ES 1 (though OpenGL ES 2 is supported too). Go change that.
Minetest is based on a fork of irrlicht, so if other irrlicht forks have actually a vulkan backend it definitly seems possible.
OpenGL 2.0 released in 2004 which was a looong time ago (wasn't even born btw).
if other irrlicht forks have actually a vulkan backend it definitly seems possible.
I didn’t say “impossible.” I said “not in the foreseeable future.” It’s a different thing entirely. Some years later it might become viable—or not. Maybe by the time Vulkan will be superseded with something else.
OpenGL 2.0 released in 2004 which was a looong time ago
Yes. And you ask to jump from that to Vulkan. It’s like jumping from a horse to a jet.
Besides, this wouldn’t buy us anything. Okay, maybe a bit better compatibility with these new shiny devices. But, even supporting non-generic shaders would require adding an entirely different codepath to Minetest, in a place which is rather hairy already (did I mention Irrlicht is built around the fixed-function pipeline [that doesn’t even exist in Vulkan, or in GL 3+ Core for that matter], with shaders bolted on?). Each non-trivial feature would require such ugly hacks.
Instead, my plan is to keep OpenGL but via a single backend (there are several currently, separate “drivers” for OpenGL, OpenGL ES, OpenGL ES 2, and my new backend that supports both GL 3+ compat. and GL ES 2+), and make the API saner. Incidentally, that would make transition to Vulkan easier but that’s definitely not a goal.
UPD: Did I say “OpenGL 2?” According to a core dev,
if other irrlicht forks have actually a vulkan backend it definitly seems possible.
I didn’t say “impossible.” I said “not in the foreseeable future.” It’s a different thing entirely. Some years later it might become viable—or not. Maybe by the time Vulkan will be superseded with something else.
WebGPU (@Desour suggestion) can be also be considered a good candidate. Minetest for the web would be really nice.
OpenGL 2.0 released in 2004 which was a looong time ago
Yes. And you ask to jump from that to Vulkan. It’s like jumping from a horse to a jet.
Yes, but then we have to move forward in smaller steps
Besides, this wouldn’t buy us anything. Okay, maybe a bit better compatibility with these new shiny devices.
Instead, my plan is to keep OpenGL but via a single backend (there are several currently, separate “drivers” for OpenGL, OpenGL ES, OpenGL ES 2, and my new backend that supports both GL 3+ compat. and GL ES 2+), and make the API saner. Incidentally, that would make transition to Vulkan easier but that’s definitely not a goal.
It's nice to see improvement to the OpenGL rendering system, but honestly the benefits of Vulcan are more than supporting shiny new devices. Vulcan have been around since almost the beginning of Minetest. Plus things like better VRR support are really great for Linux gaming.
UPD: Did I say “OpenGL 2?” According to a core dev,
That's even older 😬
Minetest for the web would be really nice.
Like Minetest for the Web? (works on WebGL)
Besides, this wouldn’t buy us anything. Okay, maybe a bit better compatibility with these new shiny devices.
the benefits of Vulcan are more than supporting shiny new devices
I didn’t mean there are no benefits. I meant Minetest wouldn’t be able to use them.
But, if you think I overestimate the complexity of adding Vulkan support show it me. Implement it. In Minetest, not some random example.
Minetest for the web would be really nice.
Like Minetest for the Web? (works on WebGL)
I am aware of this one, but last time I tried it was much slower than the desktop version, which make sense considering the architecture of WebGL. WebGPU official benchmarks shows 2x FPS difference with WebGL.
Also I would like it to be an official version.
Besides, this wouldn’t buy us anything. Okay, maybe a bit better compatibility with these new shiny devices.
the benefits of Vulcan are more than supporting shiny new devices
I didn’t mean there are no benefits. I meant Minetest wouldn’t be able to use them.
Minetest would definitely benefit from better VRR support and better handling of modern hardware. I am not speaking of RT API or anything like that.
But, if you think I overestimate the complexity of adding Vulkan support show it me. Implement it. In Minetest, not some random example.
Vulkan have a different API from OpenGL, I know that. And if I eventually get the time to learn OpenGL, Vulkan and C++, I will definitely try to.
if I eventually get the time to learn OpenGL, Vulkan and C++
Good luck. You’ll need it.
One very interesting stuff Vulkan could unlock is mesh shaders. It could allow for massive performance boost on modern GPUs.
- https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_EXT_mesh_shader.adoc
- https://docs.vulkan.org/spec/latest/chapters/shaders.html#shaders-mesh
These is a similar OpenGL 4 extension, but it's NVIDIA only.
There is a Minecraft Java mod which uses the OpenGL extension, notably for terrain rasterization which gives massive performance boost for modern NVIDIA GPUs.
- https://modrinth.com/mod/nvidium
- https://github.com/MCRcortex/nvidium/blob/dev/src/main/java/me/cortex/nvidium/renderers/PrimaryTerrainRasterizer.java
Mesh shaders are also planned for WebGPU.
One very interesting stuff Vulkan could unlock is mesh shaders. It could allow for massive performance boost on modern GPUs.
Performance-wise, there are other priorities (such as doing skinning on the GPU, or batching particles, which are both much less work) for optimizing Minetest's rendering than this neat feature which requires significant upfront investment and would have gains limited to modern devices.