Eevee shader compilation stalls, freezes OS (Windows), forces to restart computer #65939

New Issue

WenT · 2019-06-19T23:17:51+02:00

WenT commented

2019-06-19 23:17:51 +02:00

System Information:
Operating system: Windows 10 Home v1903 x64 (build 18362.175)
Graphics card: NVIDIA GeForce GT 630M (same error with integrated Intel HD Graphics 4000)

Blender Version:
Several versions since early June (have no information about previous releases), including last one: 2.80 Beta Windows 64 bit (June 19, 13:50:56 - 11c9702dd4)

Short description of error:
Shader compilation of the attached scene shaders fails after switching to Rendered view (or Render Image). It first slows down, then stalls, and ultimately freezes OS, forcing user to restart computer.

Exact steps for others to reproduce the error:
Switch to rendered view in the attached scene as it is (don't hide any items/collection, all are needed for the error to show up).
Note:
Each collection can be rendered independently. The error surfaces when all are rendered at the same time.

Due to licensing issues with the scene, I can only share it with members of the Eevee project or other developers. Leave a message here and I will send it through the specified method.

**System Information:** Operating system: Windows 10 Home v1903 x64 (build 18362.175) Graphics card: NVIDIA GeForce GT 630M (same error with integrated Intel HD Graphics 4000) **Blender Version:** Several versions since early June (have no information about previous releases), including last one: 2.80 Beta Windows 64 bit (June 19, 13:50:56 - 11c9702dd40f) **Short description of error:** Shader compilation of the attached scene shaders fails after switching to Rendered view (or Render Image). It first slows down, then stalls, and ultimately freezes OS, forcing user to restart computer. **Exact steps for others to reproduce the error:** Switch to rendered view in the attached scene as it is (don't hide any items/collection, all are needed for the error to show up). *Note:* Each collection can be rendered independently. The error surfaces when all are rendered at the same time. **Due to licensing issues with the scene, I can only share it with members of the Eevee project or other developers. Leave a message here and I will send it through the specified method.**

WenT commented

2019-06-19 23:17:51 +02:00

Added subscriber: @Desierto

Brecht Van Lommel commented

2019-06-21 12:24:53 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-06-21 12:24:53 +02:00

We normally only debug files privately or look into full production files if there is no other solution.

Is it really not possible to simplify the file to the point that it can be shared, isolating just the problematic shader nodes?

We normally only debug files privately or look into full production files if there is no other solution. Is it really not possible to simplify the file to the point that it can be shared, isolating just the problematic shader nodes?

WenT commented

2019-06-21 23:29:24 +02:00

Thanks for the response.

I could try simplifying it a bit, but as I mentioned, the bug is quite devastating and forces me to restart, so I can't iterate easily.

Also, the problem only surfaces when I try to render the whole scene. The scene itself is not that big, just a room and a character. I can render the room (with some hiccups), and character separately. I'm guessing it's some memory issue (computer has 8gb of RAM, GPU 2gb). I'm using default settings in Blender. Windows also generates massive memory dumps every time it happens.

In any case, I will try reducing the the size of it (right now it's around 300 mb with all assets packed) by removing some materials. But the licensing issues will still remain. Can't I just upload the file and only add members of the project in the visibility options? you could also tell me which other people to add.

Thanks for the response. I could try simplifying it a bit, but as I mentioned, the bug is quite devastating and forces me to restart, so I can't iterate easily. Also, the problem only surfaces when I try to render the whole scene. The scene itself is not that big, just a room and a character. I can render the room (with some hiccups), and character separately. I'm guessing it's some memory issue (computer has 8gb of RAM, GPU 2gb). I'm using default settings in Blender. Windows also generates massive memory dumps every time it happens. In any case, I will try reducing the the size of it (right now it's around 300 mb with all assets packed) by removing some materials. But the licensing issues will still remain. Can't I just upload the file and only add members of the project in the visibility options? you could also tell me which other people to add.

WenT commented

2019-07-05 16:19:41 +02:00

Hello, in the end I was finally able to find the source of the problem. The scene had several 4k textures and after changing settings so the texture "Limit Size" was 1024 (instead of the default "no limit"), the shader compilation went smoother, the program didn't stall and it rendered the scene as expected. Also when working with that limit the program didn't have those big hiccups. I also changed Image Display Method to "2D Texture".

I also disabled the auto-save feature which I found to be quite demanding on resources, and also led to hiccups (even with small .blend files).

To sum up, I don't think I found bugs but optimizations issues (unless GLSL was also part of the problem).

I think the program should be a little more conservative resource-wise, and not take over all system resources like it currently does. A warning when texture sizes are too big would be welcomed. A global ram limit setting would also be a good addition. Furthermore, is there any reason why shader compilation is not cached long-term (and saved with the project)? something like what Unreal 4 does would be great. Also separating the shader compilation phase from rendering would be cleaner and easier on the system.

Nonetheless, an important remark should be made: when rendering the same scene in Cycles (with all 4k textures and "no limit") none of these problems surfaced (it was slow but it eventually rendered, it didn't stall and freeze the entire OS like Eevee does). So I suspect the way Eevee handles shader compilation with big textures might be part of the problem too. Note: I use CPU rendering in Cycles (with 8gb of RAM), while Eevee is using the GPU (both of the GPUs gave me the same problems). The NVIDIA GPU has 2gb of memory.

So I think this Task should be closed, or relabeled to "feedback" or something like that.

Note: The presence of even a single 4k .tif normal map texture (around 10mb in size), even with a limit of 1024, slows down the rendering in Eevee considerably. This normal is plugged into a Normal Map node and then into the Normal input of a Bump node and finally into the normal input of the Principled node (so the material uses both a bump .jpg texture and normal texture). All I mentioned above only used .jpg textures, so the original problem was not related to this. This is just a side problem I found while setting up the scene.

Hello, in the end I was finally able to find the source of the problem. The scene had several 4k textures and after changing settings so the texture "Limit Size" was 1024 (instead of the default "no limit"), the shader compilation went smoother, the program didn't stall and it rendered the scene as expected. Also when working with that limit the program didn't have those big hiccups. I also changed Image Display Method to "2D Texture". I also disabled the auto-save feature which I found to be quite demanding on resources, and also led to hiccups (even with small .blend files). To sum up, I don't think I found bugs but optimizations issues (unless GLSL was also part of the problem). I think the program should be a little more conservative resource-wise, and not take over all system resources like it currently does. A warning when texture sizes are too big would be welcomed. A global ram limit setting would also be a good addition. Furthermore, is there any reason why shader compilation is not cached long-term (and saved with the project)? something like what Unreal 4 does would be great. Also separating the shader compilation phase from rendering would be cleaner and easier on the system. Nonetheless, an important remark should be made: when rendering the same scene in Cycles (with all 4k textures and "no limit") none of these problems surfaced (it was slow but it eventually rendered, it didn't stall and freeze the entire OS like Eevee does). So I suspect the way Eevee handles shader compilation with big textures might be part of the problem too. Note: I use CPU rendering in Cycles (with 8gb of RAM), while Eevee is using the GPU (both of the GPUs gave me the same problems). The NVIDIA GPU has 2gb of memory. So I think this Task should be closed, or relabeled to "feedback" or something like that. Note: The presence of even a single 4k .tif normal map texture (around 10mb in size), even with a limit of 1024, slows down the rendering in Eevee considerably. This normal is plugged into a Normal Map node and then into the Normal input of a Bump node and finally into the normal input of the Principled node (so the material uses both a bump .jpg texture and normal texture). All I mentioned above only used .jpg textures, so the original problem was not related to this. This is just a side problem I found while setting up the scene.

Brecht Van Lommel commented

2019-07-09 19:33:33 +02:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2019-07-09 19:33:33 +02:00

Brecht Van Lommel self-assigned this 2019-07-09 19:33:33 +02:00

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

Eevee shader compilation stalls, freezes OS (Windows), forces to restart computer #65939