Displacement, random render times on Dual Xeon

V-Ray for 3ds Max V-Ray for 3ds Max :: Issues
1

Hello,

about a week ago I bought a new machine.

The configuration for the new machine is:
Dual Xeon E5-2690 V3
Asus Z10PE-D8 WS (m/b)
32GB RAM DDR4 ECC
Quadro K4200
An SSD for system disk plus a few HDs

For comparison reasons the old machine is:
i7 965x (@3.55GHz)
Asus P6T Deluxe (m/b)
12GB RAM DDR3
An SSD for system disk

To the problem now.
I am using 3ds max 2015 and I have installed Vray 3.10

In one of my scenes, that I used as a benchmark to check vs my old machine, I have a big displacement map (its a 2 color B&W map of earth actually).
The old machine in a particular frame (I chose it for benchmark reasons) I got 15mins
In the New machine thats the randomness I am talking about, I get between 2:38 and 3:17
This happens in the displacement calculation stage.
In my old machine that stage takes about 6sec in the new machine takes between 30sec and 1:10!!!
I timed many times that stage.

Then I tried to remake a scene using the same item with the same displacement but without the rest of the original scene’s items, lights and textures.

There I got even more strange results.

The old machine gave a 17:18 sec with 8 sec be the displ calculation phase
The new machine took 4:30 with a 25sec (minimum) disp calc phase. Once I got a 4:14. I never got that again.
The cherry on the top of this is that if by affinity I turn off the second processor the displace calculation takes about 15sec and the render time is about 5:40 (far far away from an almost double time)
Its like the second processor barely used and the calculation takes ages.
This sounds more than a bug than anything else.
As core per core the new system is more powerful despite the lower MHz.

Even if the many cores “confuse” somehow the engine of the Vray still this could be made in such away so in that phase will use only a single core.

Thats why I am calling this a bug.

Its really funny that a 6 year old processor calculates the displacement even 10 times faster (as is random and gets that slow) than a fresh Xeon processor, that even core per core is faster.

Please any help will be much appreciated.

PS. I want also to add that, in most scenes that I have test the two machines (with no displacement), the Xeon is about 6 to 7,2 times faster.

2

Hyperthreading is on? bios problem?

3

Of course is on.

4

Come on guys… :slight_smile:

(or my English is so bad, that you cannot understand what I am talking about :frowning: )

5

Would it be possible to send us stripped down version of the scene for investigation?
Is there any difference if you set Default Geometry and Displacement mod to use Static Geometry:

What is the CPU utilization during Displacement Calculation Stage?
Try to disable Hyperthreading and run the same test for comparison.

VGDAM0R.jpg
VGDAM0R.jpg543×800 72.7 KB

6

Sorry for the delay.

I was testing almost all day to have a more complete opinion.
So if you ask me I can provide you the results.

The CPU utilization most times is 100%
Some times it goes to 70%
When is 70% I will have a longer displacement calculation time.
But if its 100% still the displacement time can be as long as in the 70%

I tried with the Hyperthreading off and still have similar confusing results.

If I put the Displacement Mod. to static I get similar results
If I put the Displacement mod. to dynamic is even slower.

An example of how weird the situation in comparison with my old pc is:

OLD PC (Dynamic geometry) 30 mins (Pre Pass 1 00:48sec) (Pre Pass 2 1min)

NEW PC
HYPER ON (Dynamic Geometry) 2 different results (as I said is always 2 different timings that occur randomly)
1st result 10:25 (PP1 4:14) (PP2 0:14)
2nd result 9:13 (PP1 3:01) (PP2 0:13)

HYPER OFF (Dynamic Geometry)
1st Result 10:59 (PP1 4:03) (PP2 00:15)
2nd result 9:31 (PP1 2:52) (PP2 0:14)

If I use the affinity to turn off all the cores/threads of Node 1 (Node 0 is CPU 1, thus Node 1 is CPU 2) then I have a strange situation
It calculates the displacement faster but when it renders all the buckets are used (from both CPUs)

Generally speaking the whole situation is very weird

I will be very glad for anyone willing to help me in this situation.
And I will be even more gratefull to people that have a similar configuration (Dual Xeon E5, I believe Ver1 Ver2 or Ver3 does not matter)

In the zip below I include both the scene and the displacement file of course.
The scene is Max 2015 though (sorry I dont have 2014 that most people still use)

There are 2 mats.
One is for using with the Default Displacement through material so the Displacement Modifier should be Off
And the other is for the Displacement Modifier either Static or Dynamic.
Displacement_test.zip (331 KB)

7

You can back-save the file to 2014 format using max. I might like to try this out on my current and new dual xeon system as well to see if I have issues.

8

I am stupid I didn’t notice that I can save as an old max version. :stuck_out_tongue:
Displacement_test_2014.zip (333 KB)

9

Doesn’t work in 2014 still. Maybe you uploaded the wrong file?

10

I am pretty sure I uploaded the right file but let me check

11

Yeap you were right.
I put a 2013 version as well, just in case
Displacement_Test_2014_2013.zip (376 KB)

12

I did a couple of tests on the attached scene into our environment and I can confirm that the Xeon processor is slower during the IM-calculation than i7.
Xeon total render time (prepass stage + final rendering) is faster than i7 total render time but the IM-calculation is slower.
This fact is true even if displacement is disabled - the difference then is not so noticeable but it is till there.

I have to discuss this behavior with our developers before submitting it as a bug.

I’ll keep you posted.

13

Interesting development. Thanks for keeping us updated.

14

Here is a IM-part of the tests we’ve performed here.
The machine on the left is i7-2600 3.4GHz the machine on the right is Xeon X5660 2.80GHz.
http://ftp.chaosgroup.com/support/scenes/i7\_vs\_xeon.avi

The video capture software was running on the i7 and yet the IM calculation is still very fast compared to twice as fast Xeon.

15

I am really glad with what you found.

At least my system is not faulty.

And feel really happy that your help and support is as good as your renderer (some times even better, like this one)

16

Hi Svetlozar,
did they accept is as bug to be corrected in the future?

17

Hello,
Svetlozar, Vlado, anyone from Vray support, please?

18

Anyone, please :face_with_spiral_eyes:

19

Do I ask something impossible?

Guys please

20

If Chaosgroup answered every bug as fast as they usually do, they would have to be inhuman (which I sometimes think they are). Since this bug, if it is one, appears to be affected by hardware I don’t think the solution will be as easily solved as implementing a new feature. Patience my friend, Rome hasn’t been built in a day either. This doesn’t affect you alone probably, as a lot of people here work on Dual Xeons, including me.