How does Cycles handle GPU thread priority and can it be changed?

Cycles Development
#1

Hi,

I am noticing that when I am rendering with Cycles using GPU on my Windows 10, the Windows gets a little bit slower but still usable. Often times, when GPU is fully utilized, entire windows becomes super choppy, but with Cycles, it just gets a bit slower, but not completely choppy.

I know there is a concept of GPU thread priority in Windows, which can be set: https://docs.microsoft.com/en-us/windows/desktop/api/dxgi/nf-dxgi-idxgidevice-setgputhreadpriority

It feels like Blender is already using it (?) but at the same time, it does not seem to be as effective as V-Ray GPU low GPU thread priority toggle, which sets GPU to the lowest priority and allows me to work and use other software while GPU is rendering. So it’s this weird state, where Cycles GPU priority is low enough to not make Windows grind to a halt, but not low enough to allow user to do something else alongside GPU rendering, such as watching video.

Is this correct? And is there perhaps some way to change the GPU thread priority in Cycles to the lowest one possible?

Thanks.

EDIT: Furthermore, it appears that Cycles GPU rendering has different priority when running as a viewport renderer VS when running as a final render. The priority of viewport renderer mode actually seems to be higher, making entire UI very sluggish when viewport render is updating. This doesn’t make much sense… Shouldn’t it be the other way around, if anything? Here’s a video showcasing the issue:


While update of viewport renderer makes the entire UI super choppy, final rendering slows down the UI a bit but still keeps it relatively fluid.

The ideal case scenario would be to have option to have very Low GPU thread priority for both viewport renderer and final renderer, so that when rendering in viewport, update doesn’t kill interactivity, and when rendering final, user can switch to other software instead of having the computer completely unusable.

I hope this can be fixed. Thanks.

EDIT2: Here’s a proof that it’s possible:

1 Like
#2

We don’t currently implement any GPU thread priority. I’m not aware of a CUDA API available to explicitly controls this, but I know some other software tries to keep things more responsive by sending smaller chunks of work (at the cost of performance regardless if other applications are using the GPU). From the documentation, this seems to be what V-Ray is doing. Certainly this could be investigated.

Note that on Linux with Pascal cards (GTX 10xx), the UI is always responsive due to compute preemption support in the driver and hardware. But this is not available yet in the Windows driver.

#3

Fair enough. Certainly some means of keeping the computer usable while rendering would help a lot. Having UI interactive in Windows while rendered viewport updates likewise.

If Cycles does not implement GPU thread priority in any way, what could possibly cause the UI performance difference between Cycles in viewport and Cycles running a final render? Would it be possible to get Cycles in viewport at the very least to have same performance hit as Cycles in the VFB?

Thanks.

#4

I’m not sure about the exact reason. It could be because the viewport uses progressive refine, maybe bigger chunks of work are sent, maybe more frequent render redraws… would need to be investigated.

#5

Any chance it will be? :slight_smile:

#6

I think it’s definitely because of larger chunks of work being sent because when you set tile size to be very large for final render it slows just as much.

I agree that keeping UI interactive is important even at cost of performance. For this reason I sometimes use CPU while doing extensive work on something and the UI lags too much with every change to the material.

#7

Hi, any news on this? Since Windows is the most popular platform Blender is used on, this should not be ignored.

To recap once more:
1, Blender UI and Windows gets very lagy when Cycles on GPU is used as a viewport renderer.
2, Blender UI and Windows gets little big laggy when Cycles on GPU is used as a final frame renderer.

It’s really sad to see this because in all of the other aspects, Blender is absolutely unmatched when it comes to responsiveness and speed of the user interface, compared to any other computer graphics software. Even software in general.

#8

Bumping this because I think it’s an issue that has big, albeit untraceable, consequences. It doesn’t happen in simple scenes but with very complex light path simulations in interiors or some exteriors it lags very much and UI is unusable unless the render border is tiny or you switch to CPU.

It especially makes sense since we now get UI overlays in Cycles.

1 Like
Blender UI paper cuts
#9

Hi, this problem is still present in latest 2.8 build.