Crash when rendering huge images on CPU 2.92.0 alpha #82042

Closed
opened 2020-10-25 00:44:51 +02:00 by Jakub Jaszewski · 14 comments

2.92.0 alpha is crashing when rendering huge images around 20.000px in width and 10.000 in height.
2.91.0, Commit date: 2020-10-31 20:46, Hash 30826a5e49 - have this problem also.
2.90.1 hash: 3e85bb34d0 don't have this problem.

Additional information is that in 2.92 after lowering the resolution so the render can start, the CPU is utilized only in ~80%.

Steps to reproduce:

  • Open default scene.
  • Set rendering engine to Cycles
  • In Properties -> Output Properties set Resolution to 19200x10800.
  • Hit F12.

system-info.txt
crash.crash.txt
crash.blend
blender_2.91.0_crash.txt

2.92.0 alpha is crashing when rendering huge images around 20.000px in width and 10.000 in height. 2.91.0, Commit date: 2020-10-31 20:46, Hash 30826a5e49c7 - have this problem also. 2.90.1 hash: 3e85bb34d0d7 don't have this problem. Additional information is that in 2.92 after lowering the resolution so the render can start, the CPU is utilized only in ~80%. Steps to reproduce: - Open default scene. - Set rendering engine to Cycles - In Properties -> Output Properties set Resolution to 19200x10800. - Hit F12. [system-info.txt](https://archive.blender.org/developer/F9075529/system-info.txt) [crash.crash.txt](https://archive.blender.org/developer/F9075534/crash.crash.txt) [crash.blend](https://archive.blender.org/developer/F9075537/crash.blend) [blender_2.91.0_crash.txt](https://archive.blender.org/developer/F9149275/blender_2.91.0_crash.txt)

Added subscriber: @silex

Added subscriber: @silex
Jakub Jaszewski changed title from Crash when rendering huge images on CPU to Crash when rendering huge images on CPU 2.92.0 aplha 2020-10-25 00:48:26 +02:00
Jakub Jaszewski changed title from Crash when rendering huge images on CPU 2.92.0 aplha to Crash when rendering huge images on CPU 2.92.0 alpha 2020-10-25 00:48:41 +02:00

Added subscriber: @iss

Added subscriber: @iss

Changed status from 'Needs Triage' to: 'Needs User Info'

Changed status from 'Needs Triage' to: 'Needs User Info'

I see following error message, so I can't check this with my GPU.
untitled.png

I see a lot of addons enabled, please click on File > Defaults > Load Factory Settings and re-check this to exclude influence of addons.

I see following error message, so I can't check this with my GPU. ![untitled.png](https://archive.blender.org/developer/F9108991/untitled.png) I see a lot of addons enabled, please click on File > Defaults > Load Factory Settings and re-check this to exclude influence of addons.

Thanks for checking this.
I should have mentioned that I dont use GPU for rendering - Cycles on CPU only.

After aplying factory defaults:
crash_2.blend
crash_2.crash.txt

The only thing that I changed were:

  • directories of temp files
  • rendering engine from Eevee to Cycles
  • render output size
Thanks for checking this. I should have mentioned that I dont use GPU for rendering - Cycles on CPU only. After aplying factory defaults: [crash_2.blend](https://archive.blender.org/developer/F9111114/crash_2.blend) [crash_2.crash.txt](https://archive.blender.org/developer/F9111117/crash_2.crash.txt) The only thing that I changed were: - directories of temp files - rendering engine from Eevee to Cycles - render output size

I couldn't reproduce crash, but I was unable to render such large image in 2.92. Rendering was very slow and got stuck on ~1%

I couldn't reproduce crash, but I was unable to render such large image in 2.92. Rendering was very slow and got stuck on ~1%

Changed status from 'Needs User Info' to: 'Confirmed'

Changed status from 'Needs User Info' to: 'Confirmed'

Thank you. I want co confirm, that on recent builds the problem persists - after launching Blender from command line I got segfault as before.
The crash occurs straight after launching render. There is no error message either.

On the surface it looks very similar to when rendering scene is too big for VRAM. But now this happens with CPU rendering.
Maybe this could be related to recently implemented tile stealing?

Thank you. I want co confirm, that on recent builds the problem persists - after launching Blender from command line I got segfault as before. The crash occurs straight after launching render. There is no error message either. On the surface it looks very similar to when rendering scene is too big for VRAM. But now this happens with CPU rendering. Maybe this could be related to recently implemented tile stealing?

Added subscriber: @Jeroen-Bakker

Added subscriber: @Jeroen-Bakker

Done quick profiling, lot of time is spent inside scaledownx() so will change tags.

Done quick profiling, lot of time is spent inside `scaledownx()` so will change tags.
Jeroen Bakker self-assigned this 2020-11-10 15:54:12 +01:00
Member

Crash happens when generating the GPU texture.

b291(_ZNK7blender3gpu7Texture12mip_size_getEiPi+0x2d) [0xc9be4bd]
b291(_ZN7blender3gpu7Texture6updateE14eGPUDataFormatPKv+0x57) [0xc9bd0cf]
b291(GPU_texture_update+0x2c) [0xc9bda2e]
Crash happens when generating the GPU texture. ``` b291(_ZNK7blender3gpu7Texture12mip_size_getEiPi+0x2d) [0xc9be4bd] b291(_ZN7blender3gpu7Texture6updateE14eGPUDataFormatPKv+0x57) [0xc9bd0cf] b291(GPU_texture_update+0x2c) [0xc9bda2e] ```

@Jeroen-Bakker There seems to be also significant performace regression with same conditions (rendering large image). I thought it could be reason of crash but it isn't.
I have made new report for this #82591

@Jeroen-Bakker There seems to be also significant performace regression with same conditions (rendering large image). I thought it could be reason of crash but it isn't. I have made new report for this #82591

This issue was referenced by 2e1498ff16

This issue was referenced by 2e1498ff16198742ba543004fd9c2c49083a6095
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Sign in to join this conversation.
5 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#82042
No description provided.