[PHI-5107] slow volume rendering on multi cpu machine

[ronald_a]

This is an issue I discussed in the vfh beta forum which has already been already identified as a bug. Just wanted to bring this over because the beta forum has been removed.

Any news on this one? Has this been fixed in the latest standalone already?

[Gosho.Genchev]

It's very high priority for the dev team but a solution has not been found yet. I'll message you once we have something.

Apologies for the delay

All the best!

[ronald_a]

Is it possible that this bug does not only affect volume rendering but rendering in general? I just started a new project (first one with the stable builds) and I am seeing some weird rendertimes where an older 12 core (dual cpu) machine) renders a frame in 7:16 and a 40 core (dual cpu) takes 04:49. a two year old 16 core does it in 2:54. Saying that, those rendertimes are from adjecent frames, so the are not 100% identical, but very similar.

[Gosho.Genchev]

We just tested with a scene containing plenty of reflective, refractive and blended materials. My 8-thread CPU took 10 minutes, a colleague's 24 thread CPU - 4 minutes.

It could be something else affecting the render times, or it could be your 16-core CPU being quite beefy. I could give you our render times with a VRScene of your choice, provided you'd like us to check with one of yours.

Cheers!

[ronald_a]

the 16 core is beefy, but not 40 core like beefy. I remember renderings where the 40 core machines would be about 80 - 100 % faster. Can you send me the testscene you used so I can give it a spin. if that works, we need to take a look at our scene.

[Gosho.Genchev]

Sure, please mail me at gosho.genchev@chaosgroup.com so I can provide you with a link.

Cheers!

[ronald_a]

Hey Gosho,

thanks for the scene. It seems to render reasonably fast compared to what you told me (3:05, 40 cores)).

This led me to do some more testing with my scene and as it turns out, the slowdown come from using alembics. In a testscene (I will be providing you via mail), the difference between using an alembic and baking the geo into the vrscene (by unpacking the alembic) is massive (1:45 to 0:25). I can currently only test this on a 40 core machine, but what I can tell from the renderstatistics, this may not be an issues for lower core machines. if possible, please test the scene on the same machine you tested the volume performance degradation with.

Cheers,

Ronny

[ronald_a]

just a little followup. I did a test on a 16 core (2 x 8 machine and the performancedegradation is much lower (0:46 --> 0:52). On another high core machine (2 x 16 the problem is the same.

[Gosho.Genchev]

Yup, got my hands on a 88-core CPU, the problem is definitely reproducible here.

Seems to be something with both the delayed load alembic *and* the material applied. I'll keep removing things from the scene until I've isolated the texture causing this. I suspect it's one of the Bercon nodes.

Thank you big time for bringing this up. I'll keep you posted with any progress on this!

[ronald_a]

Hey Gosho,

I can bake the geo into the vrscene for now because it's not that big. Hope you find a solution soon.

I do have another problem which is not related (at least I think so) to multi CPUs but I want to post it in this thread because it is related to the same scene. When I try to render the scene with motionblur (via vrscene with standalone), it does not work. And by that I mean than the geo is actually frozen on the first frame and nothing moves (this can be checked by reimporting the vrscene back into houdini). Turning off motionblur, everything seems to work/render as expected. I'll be sending you the scene via mail again (it has a small animated test cache now) so you can have a look.

1. Load up the scene and on the vray1 rop hit render to export vrscenes (with moblur).

2. re-import or render frame > 10 --> problem

3. turn of moblur on the rop, reexport

4. check again --> works (but with no moblur of course)



As you can imagine, this is somewhat urgent.

If you think we should move this topic to a new thread or off the forum, please let me know.

[ronald_a]

I just went back to the initaial official release, and the issue does not seem to be there. So this happend somewhere between then and last fridays stable

[Gosho.Genchev]

We'll bisect to find what broke this and ping the dev team to fix it ASAP.

I'll keep you posted.

[Gosho.Genchev]

ronald_a ,

starting tomorrow, the motion blur issue should be resolved in the nightlies. I also ran our tests with the new changes - as far as I can tell, nothing else was broken when fixing this.

Hope that helps!

[ronald_a]

Great news! when you say nightlies you mean not stable builds, right?

[Gosho.Genchev]

I meant the stable nightly builds, apologies if that came across confusing. You should be able to grab a new build tomorrow.