Last week a big milestone was reached: the Vulkan backend has been enabled as an experimental option. It is available in alpha builds on Linux and Windows. This option is highly experimental and enabled to collect insight on platform support. Don’t expect a fully working Blender just yet!
Why Vulkan?
Blender has been using OpenGL for a long time to draw the UI on the screen. OpenGL is a standard that was developed in 1990’s to define GPU APIs. Back then, a high end GPU had around 128MB of texture memory and geometry only existed in the main RAM of the host system.
OpenGL has tried to keep up to date with new features of GPUs and needs of developers. The API was extended to upload geometry to the GPU memory, use vertex and fragment shaders. Still, core parts of the API that were designed in the 90’s are still visible in the specification.
The specification mostly exists as a set of documents with extensions a GPU vendor could implement. The implementation details often differ per GPU vendor, with AMD trying to follow the specification as close as possible, and NVIDIA being more relaxed about it, allowing to applications handle misusing of the specification. Some extensions are vendor-specific and sometimes redundant.
Internally, GPU drivers also act differently. Optimizing an application for one vendor would not automatically improve the performance for other vendors. Drivers contain bugs as they became complex for the GPU vendor to develop. Many workarounds have been added inside Blender code base to work around driver bugs.
OpenGL decided fix these short comings by starting a project called Next Generation OpenGL Initiative. The result of this initiative lead to the development of Vulkan. Vulkan is much more than a set of API specification. It is an ecosystem with tools and driver validation processes and a place where vendors can work together in ensuring that the changes to the API are vendor-neutral.
Since the introduction of Vulkan, the OpenGL development slowed down quickly and all efforts went into Vulkan development, as vendors and application developers saw more value in that ecosystem. Currently OpenGL isn’t actively developed.
A consequence of this is that new GPU features, like hardware raytracing, mesh shaders and HDRI aren’t supported by OpenGL.
Our conclusion was that we have to migrate away from OpenGL. For Apple devices, Blender 3.5 already introduced the Metal backend. This will become the only supported backend for Apple devices in Blender 4.0. For Windows and Linux we will target Vulkan.
After finishing the migration to Vulkan, new development projects can be started utilizing the newly available GPU features. Here are some examples of projects that could be added to a future release of Blender.
- Improve the viewport performance with huge amount of geometry and complex scenes.
- Improving the quality of EEVEE by replacing screen space effects with hardware ray tracing implementations.
- Adding support for HDRI displays.
- Utilizing the compute power of GPUs in areas like texture painting.
We need your help!
The Vulkan backend is still heavily in development and will be for the upcoming time. Our next goal is to ensure that we can support as many devices as possible and that most common development configuration are supported. Blender will be able to run on any platform the supports Vulkan 1.2 with a small set of extensions and required device capabilities.
For more information about the Vulkan backend and how you can help, please check the status thread on devtalk.
Finally! A Vulkan backend for Blender! Hope to see updates in that.
I think i will try the daily build just for this xD
But i have a question: does this affect cycles? If i remember correctly Vulkan can also be used for computing, and that would be beautyful, finally no problems with HIP or others :-)
It doesn’t effect Cycles rendering and it isn’t planned that Vulkan Compute will be used for Cycles rendering.
Hope see a real viewport 60 FPS in Huge scene !!
Isn’t there MoltenVK, a bridge between Metal and Vulkan, right here: https://github.com/KhronosGroup/MoltenVK ?
So, why not use this on Apple devices, if not for rendering (it probably won’t be quite up to that), then at least for the viewport drawing? The principle of DRY: Don’t Repeat Yourself? Reusing the existing code as much as possible (but not more than that)?😉
We tried MoltenVK, but it isn’t a drop-in replacement. Many features that Vulkan requires are missing when using MoltenVK and requires more work. So DRY doesn’t work here. Examples: geometry shaders, point rendering are missing. See https://github.com/KhronosGroup/MoltenVK#compliance for more information.
Another challenge is that Vulkan prioritizes IMR devices (GPU using Immediate Mode Rendering), Metal also supports TBDR (Tile Based Deferred Rendering) what ARM GPU are build on. We have many performance improvements by adding specific TBDR code where it makes sense.
Of course we have been in contact with MoltenVK to discuss the topic.
That will be a great leap , performance will improved
“Improve the viewport performance with huge amount of geometry and complex scenes.”
Does this also include huge amounts of individual objects in the scene ?
(10K ? 100K ? 1M individual objects ?)
Hi, if i understood correctly, OpenGL backend will coexists with Vulkan backend until Vulkan backend will have at least the same feature set as OpenGL backend, and only after this feature parity, OpenGL backend will be removed?
Well, that goes without saying, right? They cannot release a Vulkan version of Blender that has missing features available in OpenGl for years.
The bare minimum for Vulkan is to be feature complete compared to OpenGL, from that point, they’ll upgrade and add features.
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.