I've yet to dabble with Karma, but a while back I got into Octane - it seemed a lot better than Redshift for technical renders like water rendering with internal scattering, volumes in general, etc... and then they brought in the Progressive Photon Mapping kernel, which has been an absolute game-changer for light propagation in water renders.

I'm assuming photon mapping isn't in Karma yet... just wondering if there's anything on the roadmap to add something similar to the Octane PPM kernel into Karma XPU? Octane is great, but I always appreciated the simple customizability of using Mantra, so it'd be good to get back to an integrated setup.

In my experience XPU variance oracle has so far always been much slower than using Uniform one, which is a bit underwhelming given that it generally uses less samples and therefore worse quality so it should at least be

Honestly I haven’t dived too deep into it yet. I just ran some basic tests, and 20.5 feels noticeably faster than version 20.

I’m not sure if it’s due to 'path guiding' or something else, but Karma XPU resolves noise in exterior scenes incredibly fast.

There are plenty of issues with Karma and MaterialX, but I won’t go into that. However, one thing I absolutely love is the combination of the 'Karma Sky Atmosphere' and 'Karma Physical Sky' nodes. They produce such a cinematic and natural look, it’s just gorgeous! The only downside is that 'Sky Atmosphere' really slows down the render.

Still, there’s something truly magical about those nodes. It’s so easy to dial in the parameters and get that perfect Star Wars Tatooine sunset/dusk vibe. Kudos to whoever developed them, it’s the best! In Redshift, environments often look plasticky without heavy post work.

BTW There's this weird parameter in the render settings, right below "Variance Threshold"
"Primary Samples - OCIO Transform (Whether to apply an OCIO transform to the pixels before measuring variance)" hm

tamte
In my experience XPU variance oracle has so far always been much slower than using Uniform one, which is a bit underwhelming given that it generally uses less samples and therefore worse quality so it should at least be faster
Maybe the variance threshold evaluation is very expensive or probably happens too often so it creates a large overhead and it often results in 3min rendrr to take 6min with variance on, which is unfortunately the default now

There is overhead, but we have an envvar that might address it.
Try setting KARMA_XPU_NUM_PER_DEVICE_BLENDING_THREADS to 2, 3 or 4 (it defaults to 1)