2.80 Crashes with 16K HDR Background World Images and Eevee Rendering #56684

New Issue

Tom M · 2018-09-04T15:19:57+02:00

Tom M commented

2018-09-04 15:19:57 +02:00

System Information

Ubuntu 18.04 and Fedora 27
i7, 16 GB RAM, Intel HD 4000 Graphics

Blender Version

Broken: version: 2.80 (sub 21), branch: blender2.8, commit date: 2018-08-31 20:43, hash: a5f950ed38
Worked: All versions in the past month or more have had this instability.

Short description of error

Eevee rendering and sometimes even loading scenes with 16K HDRI world images, such as goegap_16k.hdr from HDRI Haven, soon leads to crashes, sometimes even immediately with the default cube scene and factory settings. The crashes are somewhat random but usually occur within a minute of loading large HDR images into a complex scene and continuing scene editing.

Memory usage can jump to 80%, but even when the system stabilizes at 40-70% crashes occur. System RAM usage immediately after startup is about 8%, after loading blender it's 12%, after loading a complex scene it's 17%, after switching to Eevee rendered viewport with an 8K HDR world image it stablizes at 26% and when loading a 16K HDRI it can level at 64% for a few seconds before crashing.

In addition to instability causing crashes, scene objects appear as having distorted or transparent surfaces, both in renders and in the viewport when panning. Changing the materials/options/blend mode from Opaque to Alpha Blend, Multiply or Additive changes whether the background image is painted onto the cube surface or the cube is totally transparent. Loading 8K HDRI's is usually stable with <50% ram usage in a complex scene and no distortion in the viewport or renders.

My bandwidth is somewhat limited, so sample files are not attached, but the same HDRI's are readily available for testing from HDRI Haven. The problem occurs in both Linuxes.

Attached are system-info.txt and 16K HDRI crash from Terminal.txt

Exact steps for others to reproduce the error16K HDRI crash from Terminal.txt

system-info.txt

Adding a 16K world image and continuing scene editing leads to immediate viewing and rendering distortion and soon a crash.

**System Information** Ubuntu 18.04 and Fedora 27 i7, 16 GB RAM, Intel HD 4000 Graphics **Blender Version** Broken: version: 2.80 (sub 21), branch: blender2.8, commit date: 2018-08-31 20:43, hash: a5f950ed381 Worked: All versions in the past month or more have had this instability. **Short description of error** Eevee rendering and sometimes even loading scenes with 16K HDRI world images, such as goegap_16k.hdr from HDRI Haven, soon leads to crashes, sometimes even immediately with the default cube scene and factory settings. The crashes are somewhat random but usually occur within a minute of loading large HDR images into a complex scene and continuing scene editing. Memory usage can jump to 80%, but even when the system stabilizes at 40-70% crashes occur. System RAM usage immediately after startup is about 8%, after loading blender it's 12%, after loading a complex scene it's 17%, after switching to Eevee rendered viewport with an 8K HDR world image it stablizes at 26% and when loading a 16K HDRI it can level at 64% for a few seconds before crashing. In addition to instability causing crashes, scene objects appear as having distorted or transparent surfaces, both in renders and in the viewport when panning. Changing the materials/options/blend mode from Opaque to Alpha Blend, Multiply or Additive changes whether the background image is painted onto the cube surface or the cube is totally transparent. Loading 8K HDRI's is usually stable with <50% ram usage in a complex scene and no distortion in the viewport or renders. My bandwidth is somewhat limited, so sample files are not attached, but the same HDRI's are readily available for testing from HDRI Haven. The problem occurs in both Linuxes. Attached are system-info.txt and 16K HDRI crash from Terminal.txt **Exact steps for others to reproduce the error**[16K HDRI crash from Terminal.txt](https://archive.blender.org/developer/F4556061/16K_HDRI_crash_from_Terminal.txt) [system-info.txt](https://archive.blender.org/developer/F4556065/system-info.txt) Adding a 16K world image and continuing scene editing leads to immediate viewing and rendering distortion and soon a crash.

Tom M commented

2018-09-04 15:19:57 +02:00

Added subscriber: @tlm-3

Brecht Van Lommel commented

2018-09-04 15:43:25 +02:00

Added subscribers: @fclem, @brecht

Brecht Van Lommel commented

2018-09-04 15:43:25 +02:00

The log has this:

i965: Failed to submit batchbuffer: No space left on device

It's quite possible there is not enough memory on this graphics card to handle 16K HDRI images and the rest of the scene and operating system data.

Generally we should avoid crashing (and ideally display better error messages), and the solution here may be to simply handle the out of memory more gracefully. Part of this is beyond our control though and the graphics driver may show wrong results or crash without reporting any out of memory issues to Blender. I'll let @fclem judge what to do here.

The log has this: ``` i965: Failed to submit batchbuffer: No space left on device ``` It's quite possible there is not enough memory on this graphics card to handle 16K HDRI images and the rest of the scene and operating system data. Generally we should avoid crashing (and ideally display better error messages), and the solution here may be to simply handle the out of memory more gracefully. Part of this is beyond our control though and the graphics driver may show wrong results or crash without reporting any out of memory issues to Blender. I'll let @fclem judge what to do here.

Clément Foucault commented

2018-09-04 16:28:30 +02:00

Eevee use the raw 16K texture only for drawing the background and rendering the lower resolution probes.

The problem is that the memory management in opengl is not done by the application but by the driver and thus there is not really any way to control what is resident to the device memory or even to know how much is available.

Eevee use the raw 16K texture only for drawing the background and rendering the lower resolution probes. The problem is that the memory management in opengl is not done by the application but by the driver and thus there is not really any way to control what is resident to the device memory or even to know how much is available.

Tom M commented

2018-09-06 05:19:13 +02:00

It may be interesting to compare Blender and Gimp memory usage on the same Ubuntu 18.04.1 system.

Opening a single 16K HDRI in Gimp 2.10 requires 34% total of the 16GB memory. Adding a second similar image uses 64% of RAM. Performing sequential color balance operations bumps memory usage to 88% where it remains stable at 85-88% despite performing more operations or undoing. Oddly, opening other apps can cause system memory usage to drop to 60%, with Gimp using 7.2 GB of RAM. There is no swap memory set aside in this system.

So the Gimp developers may have some tips for managing Linux memory. I'll be testing Blender 2.80 memory usage in Windows 10 again, though my experience so far has shown less stability, despite lower RAM usage than Linux.

It may be interesting to compare Blender and Gimp memory usage on the same Ubuntu 18.04.1 system. Opening a single 16K HDRI in Gimp 2.10 requires 34% total of the 16GB memory. Adding a second similar image uses 64% of RAM. Performing sequential color balance operations bumps memory usage to 88% where it remains stable at 85-88% despite performing more operations or undoing. Oddly, opening other apps can cause system memory usage to drop to 60%, with Gimp using 7.2 GB of RAM. There is no swap memory set aside in this system. So the Gimp developers may have some tips for managing Linux memory. I'll be testing Blender 2.80 memory usage in Windows 10 again, though my experience so far has shown less stability, despite lower RAM usage than Linux.

Clément Foucault commented

2018-09-06 12:46:45 +02:00

Changed status from 'Open' to: 'Archived'

Clément Foucault closed this issue

2018-09-06 12:46:45 +02:00

Clément Foucault self-assigned this 2018-09-06 12:46:45 +02:00

Clément Foucault commented

2018-09-06 12:46:45 +02:00

@tlm-3 it does not have to do with the system memory.
It's the GPU memory (which is shared in the case of Intel's GPUs but is still much less than system RAM) that is overflowed.

Gimp does not use the GPU as much as blender because it's à 2D application and it can have conpression algorithm to reduce it. But when using an HDRI with Eevee we cannot use a compressed format because we need access to all pixel during the rendering.

I'll close this.

@tlm-3 it does not have to do with the system memory. It's the GPU memory (which is shared in the case of Intel's GPUs but is still much less than system RAM) that is overflowed. Gimp does not use the GPU as much as blender because it's à 2D application and it can have conpression algorithm to reduce it. But when using an HDRI with Eevee we cannot use a compressed format because we need access to all pixel during the rendering. I'll close this.

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

2.80 Crashes with 16K HDR Background World Images and Eevee Rendering #56684