2022-4-26 Blender Rendering Meeting

Meetings
1

Attendees

  • Brecht Van Lommel (Blender)
  • Thomas Dinges (Blender)
  • Patrick Mours (NVIDIA)
  • Christophe Hery (Facebook)
  • Brian Savery (AMD)
  • Stefan Werner (Intel)
  • Sebastian Herholz (Intel)
  • Michael Jones (Apple)
  • Juan Gea Rodriguez
  • Alex Fuller

Notes

  • Kernel specialization for scene settings and shaders: prompted by the contribution from Apple to specialize kernels to improve performance, there was a discussion of how this can work in Cycles in general. This brings up some usability questions, where users have to wait for shaders to compile or stopping renders or quitting Blender may be block since compilation can’t be interrupted.
    • For Metal, to make this approach more practical there are a few things to look into:
      • Try categorizing shaders into e.g. 3 categories like low/medium/high spill and compile kernels for each, to avoid having to compile too often.
      • Identify which scene settings have the biggest impact and specialize just on those.
      • Investigate compiler improvements to reduce compilation time
      • Improve Metal API improvements to make shader compilation interruptible.
    • PTX for CUDA/OptiX and SPIR-V for OneAPI also have some mechanisms for specialization at the bytecode level, as opposed to Metal which needs it at the source code level. Ideally an implementation could be shared but it’s not obvious that runtime compilation of source code is practical for all devices. Earlier tests for OptiX did not get a big enough improvement to be worth it, so this does not seem like a priority for now.
    • For optimal performance, specializing every shader like OSL would likely give best performance. However in other GPU renderers this compilation time in production scenes can also be long. When building the scene from scratch it’s not as bad because every individual shader can be compiled as it is being constructed. This kind of optimization is more of a longer term thing, but some possible paths here:
      • Use a mixed strategy with a single big shader first, that is then specialized. Potentially this could even be a feature of OSL, to generate such a big shader from OSL nodes. Theno SVM could be dropped entirely, though this is likely a big project and is not likely to happen soon.
      • Metal and HIP would also need OSL backends for this to be a practical, which don’t exist yet.
      • Try integrating existing OptiX OSL support and evaluate how well it works.
  • Hydra Render Delegate and USD: various build systems were made for Windows, and Cycles standalone can now render USD files in addition to XML, and should fully replace it in the future. There was a discussion about various incompatibilities in lighting and shaders. Patrick and Sebastian will work on some improvements in this area.
  • AMD HIP on Linux: this now enabled in daily 3.2 builds for RDNA and RDNA2 graphics cards. There are various reported issues in the feedback thread, Brian will gather more information so we can better understand when they happen and look into fixes. It was also mentioned that the regression tests pass with an RDNA2 cards, but there might perhaps be issues happening just with RDNA.
  • Intel OneAPI: work is underway to make everything work with the open source toolkit, to resolve licensing issues.
  • MNEE: there is a patch to be committed with fixes for bounce depth, and Brecht still hopes to look into splitting kernel but did not get around to it.

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.

19 Likes