Crash with huge texture sizes, doesn't crash when same texture is split up and put on different objects #42795

New Issue

Reginald Baxlore · 2014-12-03T23:23:28+01:00

Reginald Baxlore commented

2014-12-03 23:23:28 +01:00

System Information
win7 sp1, gtx 660 (2gb vram), i5 3570k @ 3.4ghz, 32gb ram

Blender Version
is not working in: 2.72b, 9e963ae

I have a 54k x 27k texture that i would like to use in a cycles scene, rendered with cpu. While adding the texture is working fine, trying to render results in a crash. Blender ram usage is about 5gb at this point, so nowhere near my maximum. Scaling down the texture to about 30k wont result in a crash. What's strange though: If i split the 54k x 27k texture into three seperate ones, each 18k x 27k, and put those on seperate objects they load and render fine. So in both cases the original texture is present in its entirety, however if it's not split up, it crashes.

Exact steps for others to reproduce the error

As the problem initially has do do with huge textures, it can only be reproduced by using huge textures, so this is going to be big. the zip archive is 100mb, so i cant upload here, but you'll get it here: https://mega.co.nz/#!dJQHWDiZ!e-x6_rJlr8QEF6wgyKYO1FGuiBroiIgug7gt5M22c_8 . Also you'll need over 8gb of 'available' ram to be able to reproduce the behaviour.

Steps to reproduce:

(textures have relative paths, so everything should work fine:)

open "bugreportONEBIGTEX.blend", give it a little time to load the texture (blender ram usage plateaus about at 5gb (for me)).
hit the render button or try to render in the viewport.
blender crashes
open "bugreportTHREE-THIRDS.blend", give it also a little time to load the textures (bl ram usage plateaus about at almost 8gb)
hit the render button or render in the viewport.
blender doesnt crash, but renders fine.

Conclusion: I chopped up the 'whole-tex54k' into three parts. when those three parts are used seperately, blender doesnt crash, even though the entirety of visual information would the same in both cases.

provisory steps: using smaller overall texture, chopping up texture.

Btw the texture is from nasa and free to use and distribute.

thanks

**System Information** win7 sp1, gtx 660 (2gb vram), i5 3570k @ 3.4ghz, 32gb ram **Blender Version** is not working in: 2.72b, 9e963ae I have a 54k x 27k texture that i would like to use in a cycles scene, rendered with cpu. While adding the texture is working fine, trying to render results in a crash. Blender ram usage is about 5gb at this point, so nowhere near my maximum. Scaling down the texture to about 30k wont result in a crash. What's strange though: If i split the 54k x 27k texture into three seperate ones, each 18k x 27k, and put those on seperate objects they load and render fine. So in both cases the original texture is present in its entirety, however if it's not split up, it crashes. **Exact steps for others to reproduce the error** As the problem initially has do do with huge textures, it can only be reproduced by using huge textures, so this is going to be big. the zip archive is 100mb, so i cant upload here, but you'll get it here: https://mega.co.nz/#!dJQHWDiZ!e-x6_rJlr8QEF6wgyKYO1FGuiBroiIgug7gt5M22c_8 . Also you'll need over 8gb of 'available' ram to be able to reproduce the behaviour. Steps to reproduce: (textures have relative paths, so everything should work fine:) - open "bugreportONEBIGTEX.blend", give it a little time to load the texture (blender ram usage plateaus about at 5gb (for me)). - hit the render button or try to render in the viewport. - blender crashes - open "bugreportTHREE-THIRDS.blend", give it also a little time to load the textures (bl ram usage plateaus about at almost 8gb) - hit the render button or render in the viewport. - blender doesnt crash, but renders fine. Conclusion: I chopped up the 'whole-tex54k' into three parts. when those three parts are used seperately, blender doesnt crash, even though the entirety of visual information would the same in both cases. provisory steps: using smaller overall texture, chopping up texture. Btw the texture is from nasa and free to use and distribute. thanks

Reginald Baxlore commented

2014-12-03 23:23:28 +01:00

Changed status to: 'Open'

Reginald Baxlore commented

2014-12-03 23:23:28 +01:00

Added subscriber: @blackdot

Reginald Baxlore commented

2014-12-03 23:28:47 +01:00

btw, here's the windows crash report, if that's of any use:

Problem signature:

Problem Event Name:	APPCRASH
Application Name:	blender-app.exe
Application Version:	2.7.2.0
Application Timestamp:	5446569e
Fault Module Name:	blender-app.exe
Fault Module Version:	2.7.2.0
Fault Module Timestamp:	5446569e
Exception Code:	c0000005
Exception Offset:	0000000002078039
OS Version:	6.1.7601.2.1.0.256.48
Locale ID:	2055
Additional Information 1:	021f
Additional Information 2:	021f9ce1f8187b39913fe61b16f69967
Additional Information 3:	3325
Additional Information 4:	332522e05b8f2275aaba87a8358bd7f4

btw, here's the windows crash report, if that's of any use: Problem signature: ``` Problem Event Name: APPCRASH Application Name: blender-app.exe Application Version: 2.7.2.0 Application Timestamp: 5446569e Fault Module Name: blender-app.exe Fault Module Version: 2.7.2.0 Fault Module Timestamp: 5446569e Exception Code: c0000005 Exception Offset: 0000000002078039 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 2055 Additional Information 1: 021f Additional Information 2: 021f9ce1f8187b39913fe61b16f69967 Additional Information 3: 3325 Additional Information 4: 332522e05b8f2275aaba87a8358bd7f4

Sergey Sharybin was assigned by Bastien Montagne

2014-12-04 10:14:23 +01:00

Bastien Montagne commented

2014-12-04 10:14:23 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2014-12-04 10:14:23 +01:00

Well.. One thing for sure, Blender is not using 5GB of ram when it crashes. Please note mem reporting is not always accurate, and it can especially be delayed a few seconds.

Now, 54000270004*4 = 23GB! (textures are internally represented as four floats per pixel).

Will let Sergey decide here, but pretty sure this is just a simple out-of-mem crash (the fact it works when split in three parts could be e.g. because code at some point has two copies of the same image while pre-processing it, so whole picture would give 232 = 46GB, while when split in three at most 234/3 = 31GB).

Well.. One thing for sure, Blender is **not** using 5GB of ram when it crashes. Please note mem reporting is not always accurate, and it can especially be delayed a few seconds. Now, 54000*27000*4*4 = 23GB! (textures are internally represented as four floats per pixel). Will let Sergey decide here, but pretty sure this is just a simple out-of-mem crash (the fact it works when split in three parts could be e.g. because code at some point has two copies of the same image while pre-processing it, so whole picture would give 23*2 = 46GB, while when split in three at most 23*4/3 = 31GB).

Sergey Sharybin commented

2014-12-04 13:35:21 +01:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2014-12-04 13:35:21 +01:00

Sergey Sharybin commented

2014-12-04 13:35:21 +01:00

This is byte texture, meaning it's one byte per channel, so it's more like 5.1 gig for the image.

However, Cycles by default uses OIIO and stores the image separately in the memory, This makes it so image could be 3 times in the memory during load and 2 times in the memory during render. This is to be addressed, but not considered a bug for now.

As workaround you might pack the image to the .blend file before rendering, this would make Blender and Cycles to share the same image in the memory. Ugly, but would unlock you.

Thanks for the report, but it's more a TODO, which is actually high in the list.

This is byte texture, meaning it's one byte per channel, so it's more like 5.1 gig for the image. However, Cycles by default uses OIIO and stores the image separately in the memory, This makes it so image could be 3 times in the memory during load and 2 times in the memory during render. This is to be addressed, but not considered a bug for now. As workaround you might pack the image to the .blend file before rendering, this would make Blender and Cycles to share the same image in the memory. Ugly, but would unlock you. Thanks for the report, but it's more a TODO, which is actually high in the list.

Reginald Baxlore commented

2014-12-04 13:37:57 +01:00

awesome. thanks aswell.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash with huge texture sizes, doesn't crash when same texture is split up and put on different objects #42795