CPU slow-downs extremely but speed-ups when moving render window #52360

New Issue

Michael Klein · 2017-08-12T00:58:09+02:00

Michael Klein commented

2017-08-12 00:58:09 +02:00

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).170812_Blender_Cycles_CPU_Slow-Downs.pdf

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

**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).[170812_Blender_Cycles_CPU_Slow-Downs.pdf](https://archive.blender.org/developer/F707689/170812_Blender_Cycles_CPU_Slow-Downs.pdf) 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

Michael Klein commented

2017-08-12 00:58:09 +02:00

Changed status to: 'Open'

Michael Klein commented

2017-08-12 00:58:09 +02:00

Added subscriber: @Renderbicks

Michael Klein commented

2017-08-12 01:35:38 +02:00

Here's a video capture showing the issue:

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

Here's a video capture showing the issue: https://vimeo.com/229348566 password: RB.CYCLES

Michael Klein changed title from ~~CPU slow-downs and speed-ups when moving render window~~ to CPU slow-downs extremely but speed-ups when moving render window

2017-08-12 01:46:00 +02:00

Konstantins Visnevskis commented

2017-08-12 09:37:46 +02:00

Added subscriber: @KonstantinsVisnevskis

Konstantins Visnevskis commented

2017-08-12 09:37:46 +02:00

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.

Michael Klein commented

2017-08-12 11:31:53 +02:00

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.

Brecht Van Lommel commented

2017-08-12 11:48:18 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-08-12 11:48:18 +02:00

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.

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.

Michael Klein commented

2017-08-12 12:19:04 +02:00

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.

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.

Brecht Van Lommel commented

2017-08-12 12:28:22 +02:00

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

Michael Klein commented

2017-08-12 12:49:08 +02:00

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 commented

2017-08-23 18:57:12 +02:00

Added subscriber: @Sergey

Sergey Sharybin self-assigned this 2017-08-23 18:57:12 +02:00

Sergey Sharybin commented

2017-08-23 18:57:12 +02:00

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.

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.

Max commented

2017-12-22 15:08:33 +01:00

Added subscriber: @maxim_d33

Sergey Sharybin was unassigned by Dalai Felinto

2019-12-23 16:36:34 +01:00

Germano Cavalcante commented

2020-01-16 14:34:47 +01:00

Added subscriber: @mano-wii