Cycles X: Brecht is working on optimizations for the AO pass and revamping the sampling settings. Sergey continues work on tiled and resumable rendering. Jeroen also helps with direct display of render buffers without copy to Blender. Plans is to merge this into master in about 3 weeks from now (September 20), when the 3.0 like merge window is likely to close.
Random walk SSS: various tweaks for this have been committed. Brecht is still investigating improved handling of self-intersecting meshes. Christophe mentions trace sets and an option for the number of intersections until the exit point can also help.
Manifold next event estimation: code is still being cleaned up.
AMD HIP support: initial feedback given by Brecht, William and Jeroen. Changes were so the kernel side code could be mostly deduplicated with CUDA. Host side is still duplicating a fair amount of code, may be possible to solve this but not a condition for merging. Plan to post a public patch soon in time for the 3.0 release, however drivers and compiler will not be available yet at that time. Since this can be disabled by default with a build option it’s fine to continue development like this in cycles-x/master to make things easier.
CMJ sampling: William investigated this more, and arrived at various patterns that are similar to Sobol in terms of performance/noise for a production scene. Mainly what we need here still is to validate this on a few more benchmark scenes.
Animation denoising has not been reviewed yet. We expect there is significant overlap with the work Sergey is doing regarding saving intermediate EXR files, that should simplify this.
A blog post regarding the Facebook collaboration is being worked on, Kévin has a draft, he will share it with others involved.
Eevee & Viewport
OpenSubdiv patch is being submitted soon by Kévin. Campbell volunteered to review it.
Clément comes to Amsterdam soon to discuss plans regarding Eevee 2.0, Vulkan and viewport compositing. Note these features are not going to make it for Blender 3.0.
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.
this part pretty much explains it. HIP support will have a PR soon to the cycles-x, but the driver and compiler will not be available publicly yet (these should be available before Blender 3.0 releases.)
Being cleaned up? Sounds like almost done? Will it be part of the merge? The task of New Features and Changes doesn’t seem to include it though (not even in the optional part)?
The code for MNEE has not been submitted for review by Christophe yet. Unclear if it will be ready in time for 3.0. It’s not in that task because it’s not a feature that Blender developers are working on.
No, we do not expect there to be AMD GPU rendering support on September 22. I know people want a concrete date, but we can’t give one at this point besides the 3.0 release.
@brecht There’s discussion of supporting Cycles on AMD GPUs with HIP. What are the plans for other GPUs?
From my understanding Intel GPUs will not be supported with the current Cycles-X code. Is there any work that’s being done to expand Cycles to support Intel GPUs? Or is Intel support at a stage of “we’ll wait and see what happens with the upcoming GPUs and see what Intel can offer in terms of driver support for specific APIs, general guidance, or possible code contributions.”
There’s also the question of GPU support in Cycles on MacOS. I believe I saw a note somewhere else that said it was just in the general planning stage. Is it still just that, general planning and investigation into whether or not it’s feasible?
Another question that has to be asked with regard to GPU support is what about adding support for “other GPUs” in case another GPU manufacturer starts producing something. For example currently Qualcomm makes chips with “different” GPUs from the main manufacturers. And they’re available on Windows via some Windows on ARM devices. They won’t be supported with Cycles-X code from my understanding.
Could having a more “general” backend for Cycles help with this regard. Have CUDA and OptiX and HIP and Metal for the main GPUs manufacturer now, then add a Vulkan backend as a “fallback” for other devices. Why isn’t something like Vulkan being used? Is it due to performance? The differences in programming language making certain things harder to do/program? I’m just curious.
All information that we can make public about plans for other GPUs is public, that’s all I can say about that.
Vulkan has limitations in how you can write kernels, in practice you can’t currently use pointers for example. But also, GPU vendors will recommend certain platforms for writing production renderers, provide support around that, and various renderers will use it. Choosing a different platform means you will hit more bugs and limitations, have slower or no access to certain features, are not likely to see library support like OSL, etc.
Our strategy for Cycles X is to rely on the GPU vendors to support us and provide APIs that meet our requirements. We want to support as many GPUs as possible, but not at any cost.
It’s not a workshop, just a visit to the office. There might be some updates to tasks or planning on developer.blender.org, I wouldn’t expect anything more.