Crash due to GPU memory leak when tweaking shader and light settings with Eevee #55695

New Issue

s12a · 2018-07-02T21:16:55+02:00

s12a commented

2018-07-02 21:16:55 +02:00

System Information
Windows 10 Pro 64 bit (1803)
AMD Radeon RX480 4GB with Radeon Software 18.6.1
Intel i5 3550, 8GB DDR3-1600

Blender Version
Broken: 2.8 Alpha (98d2055089) local build with Visual Studio 2017

Short description of error
When Eevee is the active render engine, tweaking any slider related to material shaders or light sources causes a GPU memory leak (visible with GPU monitoring applications, or even the new Windows 10 Task Manager), and eventually Blender crashes with the following error (on the console):

GPUTexture: texture alloc failed. Not enough Video Memory.Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF76A9E718C
Module  : D:\blender-git\build_windows__x64_vc15_Release\bin\Release\blender.exe

Exact steps for others to reproduce the error

Build Blender 2.8;
Load factory settings;
Select the default cube;
In the Properties editor > Material tab, adjust back and forth any shader slider (e.g. Roughness) repeatedly until Blender crashes.

Additional notes
It also happens with previous WHQL display drivers.
This does not happen if the render engine (from Properties editor > Scene) is set to Cycles.

Attached system info:
system-info.txt

**System Information** Windows 10 Pro 64 bit (1803) AMD Radeon RX480 4GB with Radeon Software 18.6.1 Intel i5 3550, 8GB DDR3-1600 **Blender Version** Broken: 2.8 Alpha (98d20550897) local build with Visual Studio 2017 **Short description of error** When Eevee is the active render engine, tweaking any slider related to material shaders or light sources causes a GPU memory leak (visible with GPU monitoring applications, or even the new Windows 10 Task Manager), and eventually Blender crashes with the following error (on the console): ``` GPUTexture: texture alloc failed. Not enough Video Memory.Error : EXCEPTION_ACCESS_VIOLATION Address : 0x00007FF76A9E718C Module : D:\blender-git\build_windows__x64_vc15_Release\bin\Release\blender.exe ``` **Exact steps for others to reproduce the error** 1) Build Blender 2.8; 2) Load factory settings; 3) Select the default cube; 4) In the `Properties editor > Material tab`, adjust back and forth any shader slider (e.g. `Roughness`) repeatedly until Blender crashes. **Additional notes** It also happens with previous WHQL display drivers. This does not happen if the render engine (from `Properties editor > Scene`) is set to `Cycles`. Attached system info: [system-info.txt](https://archive.blender.org/developer/F3846347/system-info.txt)

s12a commented

2018-07-02 21:16:55 +02:00

Added subscriber: @s12a

Ray molenkamp commented

2018-07-02 21:30:52 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2018-07-02 21:30:52 +02:00

Can't get it to crash on my nvidia card, but it's easy to see it completely fill up the gpu ram watching the counters in gpu-z. Looks like it's not freeing the various textures being created while making the preview, and next time it makes a preview all pointers are null again, so it re-creates them.

Clément Foucault was assigned by Ray molenkamp

2018-07-03 17:34:56 +02:00

Chris commented

2018-07-12 22:12:51 +02:00

Added subscriber: @BlenderRookie

Chris commented

2018-07-12 22:12:51 +02:00

I am having the same issue when rendering on my GTX 1060 6GB. If I try to render an animation with Eevee it will keep adding more and more to the GPU ram with each additional frame that's rendered. Eventually the GPU ram tops out and it starts filling up my system ram. Within a few hundred frames my 16GB of system ram also fills up and then blender crashes. In order to render a large animation, I must render about 100 frames and then close blender and then reopen and render another 100 frames and then repeat. It looks like it's not dumping the previous data before getting the next frames texture data.

s12a commented

2018-07-15 18:04:16 +02:00

As of the latest commit I am not able to reproduce this problem anymore.

EDIT: note that what I wrote initially was incorrect due to me not understanding correctly how to properly revert Blender to earlier commits.

As of the latest commit I am not able to reproduce this problem anymore. EDIT: note that what I wrote initially was incorrect due to me not understanding correctly how to properly revert Blender to earlier commits.

Ray molenkamp commented

2018-07-15 18:20:17 +02:00

I can still see it happily gobble up memory in gpu-z

s12a commented

2018-07-15 20:50:46 +02:00

After some investigation, it appears that 680994643c still makes GPU memory occupation increase when tweaking shaders on the default cube when EEVEE is the active rendering engine, but Blender doesn't crash right away.

GPU memory occupation does not increase anymore when tweaking shaders on 09431033e9, at least on my configuration.

After some investigation, it appears that 680994643cf76f3b0643d0fc4d8a32094431c026 still makes GPU memory occupation increase when tweaking shaders on the default cube when EEVEE is the active rendering engine, but Blender doesn't crash right away. GPU memory occupation does not increase anymore when tweaking shaders on 09431033e9e2defcea42ffe056632b4bf4fd7a2a, at least on my configuration.

Ray molenkamp commented

2018-07-19 03:53:38 +02:00

@fclem looked some more into it tonight looks like there's no texture-handles leaking (every texture created has a matching delete), however the reason the memory usage in gpu-z get so high is because once you call glDeleteTextures the texture handle gets freed, but the actual buffer in gpu memory the opengl implementation is free to do whatever it wants, including hanging on to it just in case some new texture needs it and save it self an allocation. I don't think there's an actual leak here (or at-least anymore)

Clément Foucault commented

2018-07-23 17:49:46 +02:00

Changed status from 'Open' to: 'Resolved'

Clément Foucault closed this issue

2018-07-23 17:49:46 +02:00

Clément Foucault commented

2018-07-23 17:49:46 +02:00

I fixed the leak in 5037dd8abd.

If a crash still happen it's most likely because of something else.

I fixed the leak in 5037dd8abd. If a crash still happen it's most likely because of something else.

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 due to GPU memory leak when tweaking shader and light settings with Eevee #55695