2022-07-26 Render & Cycles Meeting


  • Brecht Van Lommel (Blender)
  • Christophe Hery (Meta)
  • Brian Savery (AMD)
  • Nikita Sirgienko (Intel)
  • Patrick Mours (NVIDIA)
  • Jeffrey Liu


  • Intel OneAPI: support for this landed in Blender 3.3. For anyone with an Intel Arc GPU, feedback is welcome. The main remaining issue for the 3.3 release is ahead-of-time compilation.
  • AMD HIP: the main issue right now is the texture resolution bug on Vega/RDNA, we are hoping it will be fixed in ROCm 5.3 but this is not clear yet.
  • Apple Metal: two optimizations landed in the past few weeks, for shader sorting and intersection kernel specialization.
  • Path guiding: this was submitted for code review, currently waiting for a new OpenPGL release and updated patch. There will also be a meeting soon about integrating MNEE and path guiding.
  • Spectral: various patches from Andrii Symkin are landing to refactor code for this. No actual functionality yet, but important groundwork.
  • Principled v2: Lukas published a branch with an early (incomplete) version, there is a feedback topic with active discussion.
  • Sampling pattern: Lukas made a patch with an improved scrambling method, but more work is needed to optimize it and integrate well.
  • OptiX temporal denoise: Patrick mentions he started working on making this available from the UI.
  • Many Lights: support for surfaces is getting more complete and many issues were fixed (weekly reports, feedback), but still more work needed. From discussion, it appears that adaptive splitting may be important to handle cases where the heuristic is not ideal. Adapting splitting combined with importance resampling to keep just 1 light ray for easy GPU support will be tested.

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.


Regarding OpenPGL, right now there is no GPU support, is it planned to release this as a CPU only feature for the time being until Intel updated OpenPGL to support GPUs or will we wait for that so we get a more uniform feature set?

We will release with CPU path guiding support before there is GPU support.

1 Like

Ok, understood, thanks! :slight_smile:

I have a question regarding path guiding. From what I’ve read it can calculate caustics without the use of mnee. It looks more like metropolis light transport. If it does in fact not need mnee does that mean it can calculate both reflective and refractive caustics? Because mnee does have some nasty bugs when the light source is small. If you have a sphere and a cylinder with a glass material and have a point light set to 0 you will see alot of artifacts. And there is another another method that can calculate both reflective and refractive caustics using manifold exploration metropolis light transport (memlt). Which brings me to my next question. Will blender ever get Metropolis light transport or is going to be irrelevant by the time path guiding gets fully implemented?

Path Guiding is different from MNEE in that MNEE is focused on a specific type of caustics, while PG is a generalized path tracing improvement, meaning caustics improvement is a side effect of the general path tracing improvement. Therefore don’t expect magic, it’s not going to have instant caustics like MNEE, PG will still need to accumulate some fireflies before they form the caustics.

But because of the fact that PG is a generalized path tracing improvement, PG is more reliable in a sense that it won’t have the “nasty bugs” that MNEE has.

Some tests regarding PG’s caustics have been made, check out this BA thread:

AFAIK the plan for MNEE is to extend it to Specular Manifold Sampling at some future date.


It does both and works really well. You can try path guiding build or follow discussion here:

1 Like

Apple Metal needs a lot of work: I have an old Intel NUC that runs Linux and uses NVIDIA GeForce RTX 2080 (not the latest and greatest one, obviously) with 8GB of RAM as an eGPU, and I normally use an Intel-based Mac Mini 2018 that uses AMD Radeon RX 6800 with 16 GB of RAM (also as an eGPU, via Thunderbolt 3).
Well, the same file renders in Cycles on the NUC under one hour, and on the Mac, over three hours. That’s right: three times slower, even on a superior graphic card, a generation ahead. If Metal is that much slower that OptiX, Apple is in deep troble indeed…


A partnership with the Luxcore team would not be interesting, the speed of cycles with the quality and caustics of Luxcore would be a dream.

The RTX 2080 has hardware accelerated ray-tracing. The AMD Radeon RX 6800 has the hardware for it as well, but Metal does not take advantage of it. There’s various other factors that may affect performance, in software or hardware, but that’s a big one. It doesn’t seem very likely to me that Apple will invest in adding support for that on AMD cards when they are in the process of moving to Apple silicon.


Yes, but then how come Radeon Pro Render that also uses Metal has a better performance in the same settings? I suspect it’s Apple’s Cycles support that fails, not Metal as such: and Silicon or no, surely a trillion-dollar business has no excuse for offering second-rate quality product on any platform they still claim to support.

Better compared to what? As far as I know Radeon Pro Render does not use hardware ray-tracing on NVIDIA cards.

But it does on the AMD ones — and that proves that Metal ‘knows’ about it. My point is, Metal’s Cycles support somehow ignores the hardware raytracing : it may be something as simple as forgetting to enable it during the release. I also did notice a sharp drop in performance when I moved from Blender 3.1 to 3.2, BTW.

As far as I know there is no hardware accelerated ray-tracing for ProRender on macOS, but maybe I’m wrong.

Note that there is an experimental MetalRT option in the preferences, to use Metal’s own ray-tracing code. If hardware acceleration gets added it would be through this, but as far as I know it does not exist right now.

We haven’t noticed that in our benchmarks, but feel free to post stats in the dedicated feedback topic:

From the release notes on Radeon Pro Render 3.1 (the current version is 3.4):

Support for AMD Radeon™ RX 6700 XT graphics cards has been added.

True, it does not mention the hardware raytracing directly though.
Thanks for pointing out the experimental MetalRT option: I normally avoid anything ‘experimental’ and may have overlooked that.
And the performance drop was definitely there: the 3.1 speed was comparable to that on Linux, and the 3.2 was just outrageous –– which made me think in terms of forgotten condition compilation variable during the release (which might’ve been set correctly during the benchmarking), and some such.

Hard to say anything about a potential performance regression, but I doubt it’s a benchmark configuration issues. It’s more likely something scene specific or with specific software/hardware combination.

For reference: 3.1 and 3.2 on opendata.

For the record there OpenCL backend for ProRender only uses Hardware RT for AMD cards. The Vulkan backend is cross vendor since it’s using the official Vulkan ray tracing extension.

Not that it matters for a Metal discussion.