Karma XPU feels really slow!
19248 72 10- sekow
- Member
- 238 posts
- Joined: 11月 2013
- Offline
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 . . .
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 . . .
- jsmack
- Member
- 8026 posts
- Joined: 9月 2011
- Offline
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.
- traileverse
- Member
- 361 posts
- Joined: 11月 2015
- Offline
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!
Edited by traileverse - 2023年11月14日 16:09:53
hou.f*ckatdskmaya().forever()
- traileverse
- Member
- 361 posts
- Joined: 11月 2015
- Offline
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.
hou.f*ckatdskmaya().forever()
- brians
- スタッフ
- 526 posts
- Joined: 5月 2019
- Offline
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:
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.
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:
- 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.
- 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.
- 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_aGood 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
Disabling Embree clocks in at 29:06 which I guess is expected.
Edited by brians - 2023年11月14日 21:59:14
- traileverse
- Member
- 361 posts
- Joined: 11月 2015
- Offline
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:
- 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.
- 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.
- 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_aGood 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
Disabling Embree clocks in at 29:06 which I guess is expected.
Great news this Brian, will adaptive sampling be showing up in daily builds sometime soon or is that a next release feature?
hou.f*ckatdskmaya().forever()
- brians
- スタッフ
- 526 posts
- Joined: 5月 2019
- Offline
- traileverse
- Member
- 361 posts
- Joined: 11月 2015
- Offline
brianslong Sigh, but I'm really grateful to hear it's coming.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.
hou.f*ckatdskmaya().forever()
- traileverse
- Member
- 361 posts
- Joined: 11月 2015
- Offline
- traileverse
- Member
- 361 posts
- Joined: 11月 2015
- Offline
- Mike_A
- Member
- 269 posts
- Joined: 8月 2018
- Online
- sekow
- Member
- 238 posts
- Joined: 11月 2013
- Offline
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:
- 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.
- 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.
- 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_aGood 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
Disabling Embree clocks in at 29:06 which I guess is expected.
very much appreciated!
- jomaro
- Member
- 102 posts
- Joined: 4月 2017
- Offline
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:
- 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.
- 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.
- 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_aGood 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
Disabling Embree clocks in at 29:06 which I guess is expected.
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]
Edited by jomaro - 2023年11月15日 17:04:55
- brians
- スタッフ
- 526 posts
- Joined: 5月 2019
- Offline
- EP nineteenma
- Member
- 18 posts
- Joined: 11月 2014
- Offline
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
we are ants
- EP nineteenma
- Member
- 18 posts
- Joined: 11月 2014
- Offline
EP 十九岁Please keep path tracing alive, I love it!
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
we are ants
- EP nineteenma
- Member
- 18 posts
- Joined: 11月 2014
- Offline
亚德I think your redshift-rendered image is mapped with ACEScg
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
we are ants
- tomtm
- Member
- 133 posts
- Joined:
- Offline
- EP nineteenma
- Member
- 18 posts
- Joined: 11月 2014
- Offline
亚德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.
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.
we are ants
- Steffen Dünner
- Member
- 15 posts
- Joined: 12月 2015
- Offline
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.
Edited by Steffen Dünner - 2023年11月17日 07:34:18
-
- Quick Links