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?
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.
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âŚ
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.
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 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.
