according to this article, on Linux with Zink, the layer that runs the applications OpenGL on Vulkan, we could have performance improvement even before the new native Vulkan support arrives.
on Unigine we talk about 50% to 100% more performance than the OpenGL drivers
Where does the performance come from? Is it possible to do the same on Windows with a proprietary Vulcan driver and gain similar performance or is the performance gain Linux specific due to lack of performance of the mesa driver?
A video game benchmark and a 3D DCC like Blender are very different beasts have completely different bottlenecks.
Modern graphics APIs like Vulkan or DX12 try to remove the bottlenecks in the graphics driver area which is obviously important when throwing huge quantities of polygons at the screen at 144Hz. In a 3D DCC the bottlenecks are CPU bound tasks like deforming geometry and modifiers which are enormous compared to the bottlenecks in the graphics driver.
There may be some edge case performance improvements but moving to Vulkan is about having the opportunity to add more features than performance.
zink is an opengl wrapper for vulkan, for the moment there are new patches and being tested by the same developer of these patches, more will probably come, according to his blog. Of other facts I don’t know. I can assume that in theory it would be possible to make it work on windows (building it for it), for example dxvk which is a directx wrapper which works on vulkan, it also works on windows, but it is a dll which is used to speed up windows games on wine on linux (currently dxvk doing miracles)
It is not 50-100% more performance than the OpenGL drivers. The performance improvements are compared to the initial work the developer did on Zink, which is still far off what OpenGL delivers. It is still cool work and maybe one day it can give comparable performance, but this is one of the cases where it helps to read past the headline.
yea you are right, maybe last night I was tired and I disinterpreted the article and the excitement did the rest, but since these patches are only in the initial state, it is already a good goal, I am still optimistic.
(Other Tangent developers, I forgot to write down all the names, apologies)
Notes
Background on changes in Blender development organization
Blender development team and the number of external contributors is growing, to scale we are attempting to better organize smaller teams, in this case for rendering.
Brecht will lead the Rendering (Cycles & Eevee) team.
Another goal is to get external contributors more closely involved, and this weekly meeting is a good place to synchronize.
The goal of this meeting is to better organize rendering development, both for Blender Institute developers and other contributors, providing a place to solve problems and communicate things that fall through the cracks in asynchronous communication.
Improving cooperation in code review and bug fixing
Brecht asks for more help with code review, bug fixing, so the burden is not only on Blender Institute developers to finish and make patches ready for the Blender core and fix bugs.
Under development by Kévin, API changes are incrementally going into master. The goal is to end up with a public API that is well documented and hides internal details.
Feedback from developers integrating Cycles into other software is welcome, since this significantly affects them, but in the end should lead to simpler implementations.
Goal of Tangent is to both support Hydra in Blender and support using Cycles in other software
Priority for Tangent to get working in the near term. For the Blender Institute the focus is on more gradual USD integration in a way that is future proof, and helping external contributors (NVIDIA, Tangent, …) get their improvements compatible with and integrated into core Blender.
Tangent priorities for production rendering
Volume rendering
Issues with overlapping volumes
Improved volume stepping using algorithms like delta tracking
New particles and hair should take these issues into account. Likely involves velocity attribute on geometry rather than trying to figure out correspondence between frames in the Blender to Cycles exporter? Unclear what exactly can or needs to be done with the current system.
Tangent animation will provide more detail on the issues and proposed changes.
Lukas is looking into tile stealing for better work distribution in combined CPU and GPU rendering.
More projects to be discussed next week.
When and how to meet
This will become a weekly meeting, at the same time (Tuesday 2PM Amsterdam time).
We can always scale back and make it bi-weekly if there is not enough to discuss.
Meeting notes will be public. We want every developer (or UX designer, …) contributing to rendering in Blender to be able to join, but it’s undecided yet how to organize this in practice.
Make link to meeting public, but emphasize that this is a meeting for contributors only, for users we refer to the meeting notes.
Do not bring up confidential information in the meeting - leave that information for other channels. This is a meeting about Blender development which is all public.
Meeting will not be recorded or live streamed at this moment
Status of Ongoing Projects
Eevee Renderpasses
Under development by Jeroen, parts ready for review by Clément and Brecht
Patrick looks at optimizations and improvements still.
Brecht suggest looking into half-float to halve memory usage of the leaf nodes.
When master opens for 2.92, Brecht will ask platform maintainers to update the OpenVDB libs.
Upgrading to the nanovdb branch should be fine regarding the VFX reference platform, since the OpenVDB library has good backwards API/ABI compatibility.
Eevee NanoVDB?
No current GLSL implementation for NanoVDB, so would need to be implemented first.
Lukas works on tile stealing and GPUs rendering multiple (smaller) tiles at the same time.
Main challenge remaining is making it work well with the OpenCL split kernel, for CUDA.
Principled BSDF improvements
Lukas works on replacing the GGX multiscattering one with a faster approximation. Brecht suggest to look at Eevee implementation in case the same approach can work.
Lukas works on improved metallic fresnel in the principled BSDF. Brecht suggest to look at how the parameters are handled in Standard Surface , to share the specular color between dielectric and metallic and smoothly blend.
Network rendering
Lukas planning to contribute a (simplified) patch for this
This feature would remain disabled for official releases until it has had more testing, but it at least avoids code divergence.
Currently no support for OptiX and Embree due to BVH building needing access to Cycles data structures.
Patch adds dependency on protocol buffers, need to look into
OptiX SDK:
We will need to upgrade at some point to take advantage of newer features (curves, …).
Wait for now since it bumps the required NVIDIA driver versions, Patrick will notify brecht when it’s needed for new OptiX features.
Practical Info
This is a weekly video chat meeting for planning and discussion of Blender rendering development. Any contributor (developer, UI/UX designer, writer, …) working on rendering in Blender is welcome to join and add proposed items to the agenda.
For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.
Just checked Agenda for next week. Blender Rendering Meeting and someone from Nvidia is attending… Interesting. Wish AMD was equally interested in pushing support (direct not just funding) like Nvidia is…
For all we know AMD could be contributing far more to the Dev Fund than nVidia.
Anyway, Brian is working on a Hydra integration for Blender which is a huge feature. He hasn’t made a song and dance about it but he’s working on it.
You can bet AMD will be helping bring support to RDNA2 GPUs if they haven’t already. As is clear from the meeting notes commercial in confidence is not broadcast for all to see.
Is it the right message to demand companies work on Blender? How effective do you think that will be?
