from what little that Ive tested so far, XPU was always faster on (Linux) 3xRTXA6000 + Threadripper Pro 3995W than redshift, UNLESS refraction is involved. But Maxon is cheating there I believe as they exit out earlier than the refraction ray limit allowed for.
Which is weird...

But XPU is not faster by much to be honest. I did not test production scenes though, and always used MTLX Materials.
I prefer versatility and robustness before speed, and can not wait to leave maxon for good . . .

sniegockiszymon
Isnt translucent shader in cycles equivalent of "thinwalled"? Also in cycles you set hard limit on transparency rays, I see big difference on the right of the screen, maybe you should set more transparent rays in cycles to get closer results?

translucent is a diffuse transmission rather than the glossy transmission of thin walled. I saw a 'transparent' shader that seemed to be the equivalent, but it seemed to trap rays. It could be due to the way it computed fresnel which seems to be both faced forward and not face forward at the same time depending on the context of how its used. I couldn't find any analog to the thinwalled checkbox that worked the same.

I did increase transparent and transmission bounces to a high degree.

sekow
from what little that Ive tested so far, XPU was always faster on (Linux) 3xRTXA6000 + Threadripper Pro 3995W than redshift, UNLESS refraction is involved. But Maxon is cheating there I believe as they exit out earlier than the refraction ray limit allowed for.
Which is weird...

But XPU is not faster by much to be honest. I did not test production scenes though, and always used MTLX Materials.
I prefer versatility and robustness before speed, and can not wait to leave maxon for good . . .

Well maybe something is wrong on windows cause it’s well slow in comparison man. I’m still trying all sorts of test and it’s slow!

And also that’s one heck of a setup, surely it would be quite fast there with that CPU and triple GPU threat. Nonetheless, it should be much faster than it is on a 3090! I’m getting more and more disappointed by the minute with each comparison!

The image Karma spits out is quite nice though in comparison to redshift. Really nice. That makes it even more disappointing! Plus all the crappy glitches and errors I have to deal with using RS. It's frustrating!

I went back to the initial scene in this thread, rendered at 4K with only 64 samples, then denoised and scaled down to HD. Maybe this is how SideFX intends for the renderer to be used. I'm hoping to hear something is messed up on windows and sideFX is fixing it. If we can render at good enough samples at higher resolution, denoise, then scale down and retain detail it's workable. I'm looking at shots posted from 19.5 and I'm certain XPU looks slower now. But I never tested it so I'm not spreading propaganda.

Hi guys

Sorry to hear you've found XPU slower than expected. From our experience, there are some parts of XPU that are indeed slower than other renderers (eg lots of refraction, indirect lighting, etc...), but others where it is fast/faster (eg hair/fur). So it really depends on the scene. I notice the two examples with the most issue here are refraction-heavy (ie glass).

Plan heading forward:

1. We'll continue to look at refraction/glass to improve performance. I've just now committed an optimization (~15% speed increase) which will show up in the daily builds.
   
2. Adaptive sampling is a big one that XPU currently does not have, but we plan to get onto that soon. We expect it to give a sizeable speed boost.
   
3. We'll also be looking into the NVidia SER feature very soon, so we'll keep you posted on that too.
   

In short, we're continuing to actively improve all aspects of XPU, including performance, so keep an eye on the daily builds.
Thanks for the tests and feedback.

ronald_a
Disabling Embree clocks in at 29:06 which I guess is expected.

Good to know XPU is giving expected gains with both CPU and GPU running. I've heard other renderers tend to actually slow down when in "XPU" mode

brians
Hi guys

Sorry to hear you've found XPU slower than expected. From our experience, there are some parts of XPU that are indeed slower than other renderers (eg lots of refraction, indirect lighting, etc...), but others where it is fast/faster (eg hair/fur). So it really depends on the scene. I notice the two examples with the most issue here are refraction-heavy (ie glass).

Plan heading forward:

1. We'll continue to look at refraction/glass to improve performance. I've just now committed an optimization (~15% speed increase) which will show up in the daily builds.
   
2. Adaptive sampling is a big one that XPU currently does not have, but we plan to get onto that soon. We expect it to give a sizeable speed boost.
   
3. We'll also be looking into the NVidia SER feature very soon, so we'll keep you posted on that too.
   

In short, we're continuing to actively improve all aspects of XPU, including performance, so keep an eye on the daily builds.
Thanks for the tests and feedback.

ronald_a
Disabling Embree clocks in at 29:06 which I guess is expected.

Good to know XPU is giving expected gains with both CPU and GPU running. I've heard other renderers tend to actually slow down when in "XPU" mode

Great news this Brian, will adaptive sampling be showing up in daily builds sometime soon or is that a next release feature?

traileverse
Great news this Brian, will adaptive sampling be showing up in daily builds sometime soon or is that a next release feature?

Not sure yet, we're still in planning stage. We'll let you know when we have progress. I would expect it to be months rather than weeks though.

brians

traileverse
Great news this Brian, will adaptive sampling be showing up in daily builds sometime soon or is that a next release feature?

Not sure yet, we're still in planning stage. We'll let you know when we have progress. I would expect it to be months rather than weeks though.

long Sigh, but I'm really grateful to hear it's coming.

4k @ 64 samples denoised and scaled to HD. Quick motion! no real noticeable flickering.

bubble wrap 4k @64 samples denoised then scaled to HD - 6 mins 47 seconds

Just noted in the change log / Journal for today in build 526:

XPU: optimization (eg 15-20%) for the rendering of glass objects via MtlxStandardSurface

brians
Hi guys

Sorry to hear you've found XPU slower than expected. From our experience, there are some parts of XPU that are indeed slower than other renderers (eg lots of refraction, indirect lighting, etc...), but others where it is fast/faster (eg hair/fur). So it really depends on the scene. I notice the two examples with the most issue here are refraction-heavy (ie glass).

Plan heading forward:

1. We'll continue to look at refraction/glass to improve performance. I've just now committed an optimization (~15% speed increase) which will show up in the daily builds.
   
2. Adaptive sampling is a big one that XPU currently does not have, but we plan to get onto that soon. We expect it to give a sizeable speed boost.
   
3. We'll also be looking into the NVidia SER feature very soon, so we'll keep you posted on that too.
   

In short, we're continuing to actively improve all aspects of XPU, including performance, so keep an eye on the daily builds.
Thanks for the tests and feedback.

ronald_a
Disabling Embree clocks in at 29:06 which I guess is expected.

Good to know XPU is giving expected gains with both CPU and GPU running. I've heard other renderers tend to actually slow down when in "XPU" mode

very much appreciated!

brians
Hi guys

Sorry to hear you've found XPU slower than expected. From our experience, there are some parts of XPU that are indeed slower than other renderers (eg lots of refraction, indirect lighting, etc...), but others where it is fast/faster (eg hair/fur). So it really depends on the scene. I notice the two examples with the most issue here are refraction-heavy (ie glass).

Plan heading forward:

1. We'll continue to look at refraction/glass to improve performance. I've just now committed an optimization (~15% speed increase) which will show up in the daily builds.
   
2. Adaptive sampling is a big one that XPU currently does not have, but we plan to get onto that soon. We expect it to give a sizeable speed boost.
   
3. We'll also be looking into the NVidia SER feature very soon, so we'll keep you posted on that too.
   

In short, we're continuing to actively improve all aspects of XPU, including performance, so keep an eye on the daily builds.
Thanks for the tests and feedback.

ronald_a
Disabling Embree clocks in at 29:06 which I guess is expected.

Good to know XPU is giving expected gains with both CPU and GPU running. I've heard other renderers tend to actually slow down when in "XPU" mode

Great news!

Please have a look into the new Intel Open Path Guiding Library as well: Intel® Open PGL https://github.com/OpenPathGuidingLibrary/openpgl [github.com]

jomaro
Please have a look into the new Intel Open Path Guiding Library as well: Intel® Open PGL

We already have
Karma CPU uses it for path guiding.
But it does not work on GPU yet, so it'll be a while before we can make use of it in XPU

Karma, if I remember correctly, is a path tracing renderer. This type of GI renderer does indeed produce a lot of noise and iterates slowly when rendering closed indoor environments. The latest version, 20.0.526, has indeed improved glass rendering speed by about 10%. We can only hope that the official developers will add some biased GI like RenderMan to increase such speeds

EP 十九岁
Karma, if I remember correctly, is a path tracing renderer. This type of GI renderer does indeed produce a lot of noise and iterates slowly when rendering closed indoor environments. The latest version, 20.0.526, has indeed improved glass rendering speed by about 10%. We can only hope that the official developers will add some biased GI like RenderMan to increase such speeds

Please keep path tracing alive, I love it!

亚德
Here's another test, where Karma is just a bit slower, but looks better overall.
The material settings are the same, as well as the light setup. The backgroundplate
seems not to work in Karma XPU, so I had to create a grid with an emission not affecting
indirect rays. The thin walled option together with SSS here works really well in Karma.
Redshift was at 38sec
Karma was at 47sec

I think your redshift-rendered image is mapped with ACEScg

Hey guys,
I heard interaction in H20 is still very slow, I mean changing marerials until first pixel drawing.
I hope this will be enhanced very soon. The waiting after changing stuff in the shaders is really showbreaker.

亚德
Here's a comparison between a Redshift Render and a Karma Render, I tried to have both the same dif/refl/refr bounces and the same material, but the renders look a bit different. As if the Karma Render needed more refr bounces.
Redshift at 1m25s
Karma at 7m24s

First one is Redshift, second one Karma.

I checked and found that the reason for this difference is that only global sampling was considered, ignoring the sampling on the material ball. In Redshift, the default sampling for refraction and reflection on the material ball is 16, whereas in Karma, it is 4. This led to the illusion that despite lower global sampling in Redshift, the refraction appears more transparent.

jsmack
this is the result with Cycles. It seems to be losing a lot of energy when it stacks up in depth, even though I have indirect unclamped and 24 bounces. is it just fast because it's cheating and wrong? I would think even 4096 wrong samples would take longer than 1024 good ones.

Just in case: In Cycles you can up the "Min Transparent Bounces" to make sure Russian Roulette doesn't terminate transparent rays too early. Maybe it helps. Energy conservation / preservation shouldn't be a problem in latest Blender 4.x any more.