Attendees
- Brecht Van Lommel (Blender)
- Kévin Dietrich (Blender)
- Jeroen Bakker (Blender)
- Lukas Stockner
- Patrick Mours (NVIDIA)
- Jeff Amstutz (Intel)
- Johannes Meng (Intel)
- Sean McDuffee (Intel)
- Brian Savery (AMD)
Notes
Intel updates (Jeff Amstutz)
-
OpenVKL: volume library
- Some relevant differences compared to OpenVDB/NanoVDB:
- Supports multiple volume representations
- Efficient sampling and traversal. Likely better CPU performance than NanoVDB but no concrete comparisons made yet.
- Motion blur coming in Q4.
- No GPU support currently, but aim of OneAPI libraries in general is to work on CPU and GPU0
- Brecht: would need to have clear benefit over NanoVDB to justify the maintenance cost.
- Some relevant differences compared to OpenVDB/NanoVDB:
- OpenImageDenoise: aim is to improve library performance for faster interactive denoising.
- Embree:
- Intel is open to having ARM support, so hope is that we will not need to use a fork in the future.
- GPU may also be coming at some point.
- Anari: Khronos API for renderers. Interest in making Cycles work with this. It’s based on OSPRay which is effectively the reference implementation. Primarily used for scientific visualization now, but API is more general than that.
AMD updates (Brian Savery)
- New RDNA2 cards support hardware raytracing. AMD is working on adding support for this in Cycles, based on the OpenCL kernels. Patch planned to become public in some weeks from now.
- Cycles developers will review design and patches.
- Lukas implemented tile stealing for more efficient CPU + GPU rendering, this landed in master.
- Lukas is also investigating better CPU and GPU balancing by doing e.g. raytracing on the GPU and shading on the CPU. This could be accomplished by executing different split kernels on different devices.
- Brecht doubts if this is the right thing to prioritize, there are more fundamental optimizations to be done to improve the split kernel and improve occupancy (replacing queues/atomics with sorting, deeper refactoring of the kernel to get smaller split kernels, reducing shader globals memory, etc).
- Suggestion to precompile kernels to avoid long compilation times.
- Brecht: problem is that enabling all features makes rendering significantly slower, so not currently feasible. More fine grained split kernel would allow more to be precompiled without performance loss. AMD compiler improvements would also be welcome.
- AMD also has a GPU denoiser, similar to OptiX denoiser should be much faster on AMD GPUs compare to OIDN CPU denoising. If and how this can be supported in a GPL compatible way is unclear still, follow up over email.
SYCL, DPC++, ISPC, HIP
- AMD did some experiments with HIP support in Cycles, but no clear benefit yet, and HIP only works on Linux/ROCm drivers. Hope is that it will be supported on more platforms however and can become a viable option for writing cross-platform renderers.
- Intel: ISPC can improve CPU performance through SIMD, and also is getting GPU support.
- Hopefully converging towards more similar device languages and APIs, for the Cycles project however we need to be careful adding more backends due to the maintenance cost. No concrete decisions to be made here yet.
Ongoing Projects
- Cycles NanoVDB: not ready to be enabled yet, Patrick still investigates a bug. Even though there is some performance impact, Brecht suggest not to add an option to disable this, to keep kernels simpler for better GPU performance and easier maintenance.
- Cycles GPU regression testing: Brecht still working on this, will involve partially updates to tests to reduce GPU/CPU differences, partially separate reference images for different devices.
- Cycles API/update work by Kévin:
- BVH refit and sockets encapsulation ready to be committed
- Works on optimizing scene sync and updates (benchmarks)
- Eevee cryptomatte: Jeroen continues to work on it, now getting user testing.
- Cycles and Eevee support for accessing object properties through attribute node landed. (D2057)
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.
- Agenda
- Google Meet
- Time: Tuesday 2 to 3 PM Amsterdam Time