Next: Low Thread priority gone?

[kosso_olli]

Hey,
I have a problem here: As soon as I start to render in Next, the VFB window is getting unresponisve. The window freezes, and I can not see any progress of the render buckets until the render finishes. I can not zoom, I can not pan. In the previous releases, low thread priority fixed this issue, but I can no longer find it in the option. Was it removed on purpose? If so, why? It was usefull!

[savage309]

Is this for V-Ray or V-Ray GPU?

Best,
Blago.

[kosso_olli]

This is for CPU.
I still have to test GPU. Will report back with everything I find.

[yavor.rubenov]

Hello,
As you mention buckets I assume it's CPU. For V-Ray Next we removed the option and it is now automatically set to ON when you are rendering from inside Max. It is OFF only for DR nodes and backburner.

There was some discussion here:
https://forums.chaosgroup.com/forum/...ring-rendering

Best regards,
Yavor

[kosso_olli]

If it is always on: The problem is still persistent. The VFB window freezes. This mainly happens when all buckets are stuck on heavy parts like car headlights, where all cores are utilized at 100%.

[PIXELBOX_SRO]

do the VRAY_NUM_THREADS workaround in this case...worked for me in the end

[Syclone1]

do the VRAY_NUM_THREADS workaround in this case...worked for me in the end

Ive made a new note of that in my personal install notes to add the VRAY_NUM_THREADS and just make it 1 short of the number of threads and its been working awesome.

[yavor.rubenov]

If you are using some script to set the environment variable - you can use this:

set /a VRAY_NUM_THREADS=%NUMBER_OF_PROCESSORS%-1

that way you can use the same script on different machines

[kosso_olli]

Can somebody please explain step by step what I need to do to stop that VFB freezing/flashing error. I am on Next trial, and this is annoying as hell.
Also, can this fix please be integrated into every V-Ray install? Doing this on a render farm with 10 nodes is no fun.

[vlado]

So far we believe that the reason for the problem is not in V-Ray but somewhere else as it happens with other renderers/applications too, with various frequencies. We have looked for multiple work-arounds, but so far there isn't a reliable one.

On an interactive machine, you can set the number of threads to one below the number of cores, as Yavor explained above. To make the change permanent, you can use the setx command instead of set. This is for an artist workstation though - I'm not sure why you would need to do this on a render farm? I thought the goal was to have all render slaves CPUs to be maximally utilized on the farm.

Best regards,
Vlado

[kosso_olli]

To make the change permanent, you can use the setx command instead of set. This is for an artist workstation though - I'm not sure why you would need to do this on a render farm? I thought the goal was to have all render slaves CPUs to be maximally utilized on the farm.

That's totally true. So forget about the part with the render farm of course.
Just tested the environment variable on my workstation, will repot back.
Interesting to know this happens on other software as well. Is there any way to make this reproducable on your end?

Regards

Oliver

[^Lele^]

the one reliable way to not get issues is to not have an dx/openGL hardware driver installed, seemingly.
Working with remote machines never shows the issue (at least in windows 7, which i have tested).
It's also common not just to renderers, but other cpu-intensive applications (i got it building trees, terrains, well outside of the scope of max, or even Qt).
The one thing they all do in common is to use all cores hard, for extended periods of time, while having also to draw a viewport.

[kosso_olli]

the one reliable way to not get issues is to not have an dx/openGL hardware driver installed, seemingly.
Working with remote machines never shows the issue (at least in windows 7, which i have tested).
It's also common not just to renderers, but other cpu-intensive applications (i got it building trees, terrains, well outside of the scope of max, or even Qt).
The one thing they all do in common is to use all cores hard, for extended periods of time, while having also to draw a viewport.

We have the same experience here, on our render nodes it does not show the problem, they have no GPU. All cores have to be at full throttle, thats true. Never encountered it anywhere else though, cause Max is the only software we have to fully utilize all cores.

[^Lele^]

I had instances with world machine and speedtree cinema.
In both cases, i had these truly epic sized build tasks, which brought the workstation to its knees (at the tune of 256 gb++ of ram needed, for some instances...).
That's when it started happening, albeit with a different frequency of the flickering for each app (and ofc running scenario).
The unruly behaviour while the app was running though, was identical (focus, and so on).

[burakumincgi]

Hello,
As you mention buckets I assume it's CPU. For V-Ray Next we removed the option and it is now automatically set to ON when you are rendering from inside Max. It is OFF only for DR nodes and backburner.

There was some discussion here:
https://forums.chaosgroup.com/forum/...ring-rendering

Best regards,
Yavor

not sure it's working, the frame buffer freezes the pc during rendering unless I manually assign a low thread priority to max via the task manager.