Page MenuHome

Crash due to GPU memory leak when tweaking shader and light settings with Eevee
Closed, ResolvedPublic


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:

Event Timeline

Ray molenkamp (LazyDodo) lowered the priority of this task from 90 to 50.EditedJul 2 2018, 9:30 PM

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.

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 (s12a) added a comment.EditedJul 15 2018, 6:04 PM

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.

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

s12a (s12a) added a comment.EditedJul 15 2018, 8:50 PM

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.

@Clément Foucault (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 (fclem) changed the task status from Unknown Status to Resolved.Jul 23 2018, 5:49 PM

I fixed the leak in rB5037dd8abdf9335e998141336d4e15f81580c491.

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