CPU slow-downs extremely but speed-ups when moving render window
Open, ConfirmedPublic

Description

System Information
WIN 10 latest GTX 780 DELL Xeon System

Blender Version
Broken: 2.79-0398ee1-win64-vc14
Worked: n.a.

Short description of error
I am rendering a scene in 16K resolution. In the beginning it was fine. Then I realized slow-downs in the transparent area of the picture.
When I move the window the tiles start to speed-up dramatically and render in a speed the empty area as expected.
When I stop moving the window it slows-down extremely. When the tiles start to render geometry the CPU performance in the task manager is at 100%.
When it comes to the transparent areas the CPU slows down dramatically till I move the window again.
But also here I realized now that the render speed in the geometry areas will slow-down if I keep the window in foreground.
When I close the window to background the speed goes up to 100% then.
But once it will reach the transparent area again in background the speed slows down to around 30%.

Crazy. I can't say if this is the size of the rendering. The scene render takes around 15GB of my RAM (32GB).

Attached you'll see screenshots of the CPU effect,

Exact steps for others to reproduce the error
I can upload the complete scene if necessary. The render will

Details

Type
Bug

Here's a video capture showing the issue:

https://vimeo.com/229348566
password: RB.CYCLES

Michael Klein (Renderbricks) renamed this task from CPU slow-downs and speed-ups when moving render window to CPU slow-downs extremely but speed-ups when moving render window.Aug 12 2017, 1:46 AM

Task manager graph shows CPU utilization not speed. It is logical that there's less computation while fetching transparent tiles, hence the lower utilization. Also the model seems to have relatively simple shader, hence not a big difference in render speed between geometry and background.

No. That's not the point. Watch my recoreded video and you will see that the speed of the tiles in the transparent areas slow-down extremely. When moving the window they start to render in an expected and correct speed. It's not correct that the tiles will take ages in the transparent area. The same issue you'll have randomly in the areas with geometry. When moving the window the rendering speeds up to the maximum speed. When minimizing the window the geometry area seems be rendered efficiently till it comes to the transparent area. The slow-downs and sometimes freezes of tiles is not normal.

There is likely some kind of bottleneck in drawing huge resolution images, and moving the render windows stops it from redrawing. Such a bottleneck will have a bigger impact in transparent tiles that render quickly.

You could try changing User Preferences > System > Images Draw Method. Also rendering without a render window will probably be fast.

Brecht Van Lommel (brecht) triaged this task as Normal priority.Aug 12 2017, 11:48 AM

Hi Brecht,

thanks for the hint. I will try this and come back. Yes, I assume that this effect in my video is caused by the extreme high resolution of the image.

But I have the impression it's not only a redraw issue. It really slows down as long as I don't move the window.

It's because Cycles can be blocked by the drawing code when handing Blender the tile data.

OK. What I do now . I start the render and zoom in. When I zoom out the tiles slow down and the estimated render time is over 12 hours. When I zoom in at a maximum the tiles speed up and the estimated render time is now 5 hours. Looks like this is a fair workaround. :-)

Sergey Sharybin (sergey) raised the priority of this task from Normal to Confirmed.

The slowdown is caused by the current architecture: image drawing will lock the render result from writing for the whole period of draw, which makes it so all render threads will wait for the lock to be released when they are communicating result from Cycles to Blender. On such resolution it wouldn't really matter which image draw method is used: when the whole image is visible the whole 16k image needs to pushed to the GPU.

I'm now experimenting with an approach when render threads only tags specific tiles as dirty, and then drawing thread will release all locks as soon as possible. The concept seems to be working ok, but there are some glitches to be fixed still and would need to verify over all the corner cases of render pipeline.