Last month we continued on the Vulkan Backend development. The target of this quarter is to get the performance of the Vulkan backend at least to the same level as OpenGL (but most likely better). Vulkan backend is by intention implemented to be accurate and not performant. This gave us time to get familiar with the eco-system and check the different technical requirement that Blender has (compared to games) and the best approach is to solve it.
The solution is to implement a render graph. The key difference (compared to a regular render graph) is that Blender uses the render graph to track resources between multiple render threads to improve pipeline barrier generation.
The last month has been spent on finalizing the design, reviewing the core implementation and porting buffers, textures, compute and indirect compute to the new design. Many changes have already landed into main. However we can only activate the render graph by default after the drawing and swap chains have been ported as well. This will be the short term target for next month.
To ease the development we are looking into some extensions that are widely supported. Dynamic rendering seems to be widely supported and removes the strict creation of render pass and framebuffer resources. Graphics libraries is another extension, sadly it isnât widely supported so we will post-pone its implementation until further notice.
When we are able to start blender with the new render graph the focus will move towards adding the newly introduced features that is required for EEVEE-Next. As I was helping our EEVEE-Next I wasnât able to implement these features to the Vulkan Backend. See https://projects.blender.org/blender/blender/issues/68990 for a detailed list and how we intent to implement them.
Is Vulkan compatible with dual ( or multiple ) GPU to increase viewport/rendering EEVEE ( NEXT) performances ?
Could be possible to select the GPU ( or multiple GPUs ) for Vulkan compute in multi GPU setup ?
I plan to setup a new system with two discrete GPU ( AMD and/or Intel) for Cycles but it would be very useful if multiple GPUs could increase Vulkan performances.
GPU selection is already implemented. It still need to be made visible in the preferences and via a command line parameter. This is planned when the backend is stable enough to be part of a actual release.
Multi GPU rendering (inside a single Blender process) doesnât provide what you would expect but adds a lot of complexity and could also impact single GPU rendering performance.
Depth precision is different between GPUs, can lead to popping artifacts.
Shaders are compiled different leading to different results.
Increase of complexity in resource management, resource state tracking and resource synchronization that would lead to not the expected performance. But adds a lot of maintenance/testing work for developers.
Different logic as GPU can have different feature sets/optimization tricks.
Just to name a few. If you have two similar GPUs (doesnât have to be exact the same) I would suggest to setup a small render farm (using flamenco for example) and use 2 different blender instances for rendering animations. This will ensure that the max performance of both GPUs can be used without these limitations. Although this would require more RAM for rendering.
I might be misunderstanding your comment, but are you complaining about the fact you canât get most versions of Blender to run on your Qualcomm processor?
If so this is expected. All modern versions of Blender need OpenGL features that your processor does not support. Iâm not sure about Vulkan, but I also assume itâs not support.
Along with that, most version of Blender arenât compiled with ARM support. You can try running Blender with CPU translation/emulation, but Iâm not sure what translation features your CPU has acess too, or if it works properly with Blender.
Something I noticed when testing the backend. Compiling specific shaders on EEVEE seems to be over 20x faster.
For example changing Shadow Rays and Steps. Using OpenGL, changing the value for either of those will result in a shader compilation taking up to 40s-1m, while in Vulkan the same takes ~2s, but it hangs the UI which I imagine is a known issue.
Yes that speedup is correct! In OpenGL you can improve the performance by adjusting Preferences -> System -> Memory & Limits -> Max Shader Compilation Subprocesses.
The hanging of the UI is known and I am thinkering a solution for it. The cause is that device specific optimization step is still done in the main thread for graphic based shaders. I have noted it in #130131 - Vulkan: Performance (Meta) - blender - Blender Projects
In OpenGL you can improve the performance by adjusting Preferences -> System -> Memory & Limits -> Max Shader Compilation Subprocesses .
I mentioned this to begin with because the 40s-1m time was with Subprocesses already set up (12, the amount of logical threads on my CPU as seen on the task manager). But this made me want to test it and it turns out Subprocesses set to 0 somehow makes it faster?? Doing some brief testing any value over 0 is slower than it.
This might be specific to changing the shadow ray values but still something Iâve just ran into.
Not wanting to hijack the Vulkan thread, so feel free to dismiss my comment, but I also notice that max shader compilation subprocesses, while it does provide a speedup on my system of roughly 2x in total, doesnât seem to multithread well. Iâve set mine to 24 subprocesses, but while compilation is still running, most threads never go past 0.2 percent load:
Only the main thread is fully busy (8.6% is one core fully busy on my 12th gen Core i9), the others Iâm not sure if the reported values are wrong, or something else is going on.
It is hard to say from only a single screen shot. If you think it is a bug it is best to report so we can find out if it is expected behavior or something is failing.
Multi processes only works for engine compilation and material compilation. It doesnât use all the subprocesses to compile a single shader so it depends on the workload and size of the shaders how well it works. Shaders that are already compiled are loaded from disk. Drivers may still need time to process these as well.
True, they have released last year a new API to support modern GPU backend, however it isnât an drop in replacement and requires in-depth changes in Blender. Expectation to be 2-3 months of development work.
It is something I want to look into after Vulkan backend is stable, but unsure when the project will start.
