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.