Performace regression in Blender 2.83 and Blender 2.90 compared with Blender 2.82a #76890

New Issue

Marcus Papathoma · 2020-05-19T18:15:34+02:00

Marcus Papathoma commented

2020-05-19 18:15:34 +02:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.92

Blender Version
Broken: version: 2.83 (sub 17), branch: master, commit date: 2020-05-18 23:31, hash: ff7a30d928
Worked: 2.82a

Short description of error
When working on a larger scene (13000 objects, 24million polys) in blender 2.83 and 2.90, the programm is often freezing for a few seconds. It is not a special task where blender freezes, but the only things I´m doing is orbiting around, selecting objects and assinging materials to them.
I experienced this behavior two weeks ago where I first tested blender 2.83 and 2.90. I thought maybe it will improve but compared to blender 2.82a it is reals noticeable and you can´t work with the newer blender versions. For me it is a big regression!
Sorry I can´t share a file because it is from a client.
But I created another file, where you can see what I mean. Because we need to produce a big file a few steps need to be done.

Exact steps for others to reproduce the error
Open the attached blend file.
performance_regression_test.blend
You see boxes, select them step by step and raise the count in each array to about 3500.

Then apply every array modifier.

Then select one new box object go into edit mode, hit p to seperate by loose parts. Do this with all the five cube objects.
If you have done everything right you should have about 17499 seperate cubes.

Obit now around select a few cubes and assign shaders to them. ( I included lots of shaders in the scene). Do this a while, select sometimes more cubes and assign shaders.
With blender 2.82a it works relatively smooth. Sometimes the selection of the cubes is a little bit slow.

Do the same prozess from start to end with blender 2.83 or 2.90.
The preperation tasks to get all the cubes is a little bit slower as in 2.82a but when you are selecting objects and assinging shaders blender 2.83 and 2.90 are often freezing and the loading mousepointer is shown for a few seconds.
With this approach I can reproduce the performance regression! At work I often do such tasks (shading cars or motorcycles) and now with blender 2.83 and blender 2.90 its nearly impossible to get the objects selected and shaded because of freezes every now and then.

I hope you can also reproduce it and solve the problem!
I like blender and if this regression problem persists, I would be stuck to blender 2.82a.

Greetings

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.92 **Blender Version** Broken: version: 2.83 (sub 17), branch: master, commit date: 2020-05-18 23:31, hash: `ff7a30d928` Worked: 2.82a **Short description of error** When working on a larger scene (13000 objects, 24million polys) in blender 2.83 and 2.90, the programm is often freezing for a few seconds. It is not a special task where blender freezes, but the only things I´m doing is orbiting around, selecting objects and assinging materials to them. I experienced this behavior two weeks ago where I first tested blender 2.83 and 2.90. I thought maybe it will improve but compared to blender 2.82a it is reals noticeable and you can´t work with the newer blender versions. For me it is a **big regression!** Sorry I can´t share a file because it is from a client. But I created another file, where you can see what I mean. Because we need to produce a big file a few steps need to be done. **Exact steps for others to reproduce the error** Open the attached blend file. [performance_regression_test.blend](https://archive.blender.org/developer/F8543412/performance_regression_test.blend) You see boxes, select them step by step and raise the count in each array to about 3500. ![performance_regression_01.jpg](https://archive.blender.org/developer/F8543419/performance_regression_01.jpg) Then apply every array modifier. ![performance_regression_02.jpg](https://archive.blender.org/developer/F8543426/performance_regression_02.jpg) Then select one new box object go into edit mode, hit p to seperate by loose parts. Do this with all the five cube objects. If you have done everything right you should have about 17499 seperate cubes. ![performance_regression_03.jpg](https://archive.blender.org/developer/F8543438/performance_regression_03.jpg) Obit now around select a few cubes and assign shaders to them. ( I included lots of shaders in the scene). Do this a while, select sometimes more cubes and assign shaders. With blender 2.82a it works relatively smooth. Sometimes the selection of the cubes is a little bit slow. ![performance_regression_04.jpg](https://archive.blender.org/developer/F8543456/performance_regression_04.jpg) Do the same prozess from start to end with blender 2.83 or 2.90. The preperation tasks to get all the cubes is a little bit slower as in 2.82a but when you are selecting objects and assinging shaders blender 2.83 and 2.90 are often freezing and the loading mousepointer is shown for a few seconds. With this approach I can reproduce the performance regression! At work I often do such tasks (shading cars or motorcycles) and now with blender 2.83 and blender 2.90 its nearly impossible to get the objects selected and shaded because of freezes every now and then. I hope you can also reproduce it and solve the problem! I like blender and if this regression problem persists, I would be stuck to blender 2.82a. Greetings

Marcus Papathoma commented

2020-05-19 18:15:34 +02:00

Added subscriber: @machieb

Marcus Papathoma changed title from ~~Performace regression - Blender 2.83 and Blender 2.90~~ to Performace regression in Blender 2.83 and Blender 2.90 compared with Blender 2.82a

2020-05-19 20:51:15 +02:00

Marcus Papathoma commented

2020-05-20 12:05:25 +02:00

What I forgot to mention is, I tested also on different computers, so it is not a hardware specific problem.

Alaska commented

2020-05-20 12:28:59 +02:00

Added subscriber: @Alaska

Alaska commented

2020-05-20 12:28:59 +02:00

I've done a bunch of testing and I'm unable to notice the freezing and loading issues you're describing when comparing 2.82a and 2.83 dfe8195dfe (2020-05-19 23:15).

Linux-5.4.0-7626-generic-x86_64-with-debian-bullseye
GTX 1050Ti 440.82
Ryzen 9 3900X
2x16GB 3200Mhz RAM

I haven't attached a debugger and monitored what's going on (because I don't know how). Maybe someone else with more experience in this kind of thing could help out.
It's also possible that this issue is Windows only. Just throwing some ideas out there.

I've done a bunch of testing and I'm unable to notice the freezing and loading issues you're describing when comparing 2.82a and 2.83 `dfe8195dfe` (2020-05-19 23:15). Linux-5.4.0-7626-generic-x86_64-with-debian-bullseye GTX 1050Ti 440.82 Ryzen 9 3900X 2x16GB 3200Mhz RAM I haven't attached a debugger and monitored what's going on (because I don't know how). Maybe someone else with more experience in this kind of thing could help out. It's also possible that this issue is Windows only. Just throwing some ideas out there.

Marcus Papathoma commented

2020-05-20 14:13:43 +02:00

Maybe it is only a issue on Windows OS?

I tested on three machines:

PC1:
Windows 10
GTX 1080 Ti
Threadripper 1950X
64GB RAM

PC2:
Windows 10
GTX 1080 Ti
2x Xeon E5-2697 v3
128GM RAM

PC3:
Windows 10
Quadro M5000M
Xeon E3-1535M v5
64GB RAM

On every computer I get the freezing and loading issues with blender 2.83 and 2.90.

In the moment I´m working on blender 2.82a and have no problems. But as I mentioned with blender 2.83 and 2.90 its not possible to work.

Maybe it is only a issue on Windows OS? I tested on three machines: PC1: Windows 10 GTX 1080 Ti Threadripper 1950X 64GB RAM PC2: Windows 10 GTX 1080 Ti 2x Xeon E5-2697 v3 128GM RAM PC3: Windows 10 Quadro M5000M Xeon E3-1535M v5 64GB RAM On every computer I get the freezing and loading issues with blender 2.83 and 2.90. In the moment I´m working on blender 2.82a and have no problems. But as I mentioned with blender 2.83 and 2.90 its not possible to work.

Germano Cavalcante commented

2020-05-20 22:08:11 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-05-20 22:08:11 +02:00

I can not reproduce and described regression.
It is worth mentioning that these steps result in a large memory consumption.
So to be fair you need to close the other blender instances when testing each version.

Operating system: Windows-10-10.0.18941 64 Bits
Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13586 Core Profile Context 19.50.01.05 26.20.15001.5006

I can not reproduce and described regression. It is worth mentioning that these steps result in a large memory consumption. So to be fair you need to close the other blender instances when testing each version. ---- **Operating system:** Windows-10-10.0.18941 64 Bits **Graphics card:** Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13586 Core Profile Context 19.50.01.05 26.20.15001.5006

Marcus Papathoma commented

2020-05-21 12:07:48 +02:00

I only have one blender instance open.
I work with blender nearly every day at work since january 2015.
I have to make renderings of cars and motorcyles. I get the CAD data from the vendor, import them as an fbx, shade and organize the parts in blender.
So I have bigger scenes with about 10000-20000 Objects and 20million to 40million polygons. But that was never a problem so far!

But with blender 2.83/2.90 this is not possible to work fluently anymore because of constant freezes and loading.

Maybe you have to include more task into your testing. Rename objects, group objects, create collections etc. After a few tasks I get the freezing while testing with the above described scene.
How can you explain that if I work on the same scene in blender 2.82a I have no freezes and what so ever?

I only have one blender instance open. I work with blender nearly every day at work since january 2015. I have to make renderings of cars and motorcyles. I get the CAD data from the vendor, import them as an fbx, shade and organize the parts in blender. So I have bigger scenes with about 10000-20000 Objects and 20million to 40million polygons. But that was never a problem so far! But with blender 2.83/2.90 this is not possible to work fluently anymore because of constant freezes and loading. Maybe you have to include more task into your testing. Rename objects, group objects, create collections etc. After a few tasks I get the freezing while testing with the above described scene. How can you explain that if I work on the same scene in blender 2.82a I have no freezes and what so ever?

Alaska commented

2020-05-21 13:58:47 +02:00

How can you explain that if I work on the same scene in blender 2.82a I have no freezes and what so ever?

Sometimes there's weird bugs that only occur on a portion of users setups. For example, there was a graphical glitch that was patched about a week ago. The glitch appear as a bunch of square artifacts when working with high poly objects in edit mode. It was confirmed to only affect Nvidia GPUs and occurred on both Windows and Linux, but could not be reliably reproduced. Some people with a certain GPU generation and driver could reproduce the issue while others with very similar setups could not. It could be that the 3 computers you've tested on are ones that experience this type of performance regression while I and @mano-wii are unable to reproduce the issue due to having very different setups. You have to keep in mind there are thousands of different computer hardware configurations and millions of different software configurations. A issue reproducible for one user isn't always going to be reproducible by another. You also have to keep in mind that out of all those billions of configurations of hardware plus software, only 5 computers have been tested.

As for running the test again with renaming objects, creating collections, moving objects, changing materials, etc. I've done that and I'm still unable to reproduce the performance regression you describe.

It's possible you could help by providing debugging information. However, I'm not the person to talk to about setting that up as I personally haven't got a debugger setup and the process for Linux (what I'm using) will be different from Windows (what you're using). Maybe someone else can help you out with setting that up.

I wish you luck with getting this sorted. And if the issue can't be fixed by Blender 2.83 release, hopefully it can be fixed by 2.90 or a 2.83 LTS patch.

> How can you explain that if I work on the same scene in blender 2.82a I have no freezes and what so ever? Sometimes there's weird bugs that only occur on a portion of users setups. For example, there was a graphical glitch that was patched about a week ago. The glitch appear as a bunch of square artifacts when working with high poly objects in edit mode. It was confirmed to only affect Nvidia GPUs and occurred on both Windows and Linux, but could not be reliably reproduced. Some people with a certain GPU generation and driver could reproduce the issue while others with very similar setups could not. It could be that the 3 computers you've tested on are ones that experience this type of performance regression while I and @mano-wii are unable to reproduce the issue due to having very different setups. You have to keep in mind there are thousands of different computer hardware configurations and millions of different software configurations. A issue reproducible for one user isn't always going to be reproducible by another. You also have to keep in mind that out of all those billions of configurations of hardware plus software, only 5 computers have been tested. As for running the test again with renaming objects, creating collections, moving objects, changing materials, etc. I've done that and I'm still unable to reproduce the performance regression you describe. It's possible you could help by providing debugging information. However, I'm not the person to talk to about setting that up as I personally haven't got a debugger setup and the process for Linux (what I'm using) will be different from Windows (what you're using). Maybe someone else can help you out with setting that up. I wish you luck with getting this sorted. And if the issue can't be fixed by Blender 2.83 release, hopefully it can be fixed by 2.90 or a 2.83 LTS patch.

Marcus Papathoma commented

2020-05-21 19:41:38 +02:00

Ok thank you, I can understand that there are thousands of computer configurations out there.
I will keep testing on and maybe the problem will be solved by a patch or I can create a more reproduceable scene.

Ok thank you, I can understand that there are thousands of computer configurations out there. I will keep testing on and maybe the problem will be solved by a patch or I can create a more reproduceable scene.

Marcus Papathoma commented

2020-05-21 19:42:11 +02:00

Changed status from 'Needs Triage' to: 'Archived'

Marcus Papathoma closed this issue

2020-05-21 19:42:11 +02:00

Germano Cavalcante commented

2020-05-21 20:55:45 +02:00

@machieb,
If you can replicate the problem consistently then the report is still valid.
We just need to wait for a developer with a similar setup to be able to replicate.

@machieb, If you can replicate the problem consistently then the report is still valid. We just need to wait for a developer with a similar setup to be able to replicate.

Alaska commented

2020-05-22 06:02:34 +02:00

Changed status from 'Archived' to: 'Needs Developer To Reproduce'

Alaska reopened this issue

2020-05-22 06:02:34 +02:00

Stefano Bonicatti commented

2020-05-30 18:07:43 +02:00

Added subscriber: @Smjert

Stefano Bonicatti commented

2020-05-30 18:07:43 +02:00

I see it happening sometimes on my machine too:
Blender 2.90 (2ee94c954d)

ArchLinux
NVIDIA GTX 1080
Intel i7 6700k
32GB RAM

When you open the .blend file you have the red cubes selected, if you deselect them by clicking in the background you can already see that it takes a bit more than it should (but we are talking about 250-500ms), because when you select it again and then deselect it is instant.

A longer hang happens sometimes when selecting the green cubes, switching to the material properties tab and then selecting the yellow cubes.
If it didn't happen then, then deselect the yellow cubes by clicking the background, it should hang.

Again it doesn't always happen, and it doesn't always happen with the same steps; another one I've seen is: open blend, deselect currently select cubes, switch to the material properties tab, select green cubes, switch to the render properties tab.

I'll try to play a bit with perf, I don't guarantee anything ^^'.

EDIT:
To be fair though, I see the same behavior on 2.82a; the hang I'm talking about is like a ~2s delay in selecting or deselecting the cubes.

I see it happening sometimes on my machine too: Blender 2.90 (2ee94c954d6700a45fde320f330964bcf1888545) ArchLinux NVIDIA GTX 1080 Intel i7 6700k 32GB RAM When you open the .blend file you have the red cubes selected, if you deselect them by clicking in the background you can already see that it takes a bit more than it should (but we are talking about 250-500ms), because when you select it again and then deselect it is instant. A longer hang happens sometimes when selecting the green cubes, switching to the material properties tab and then selecting the yellow cubes. If it didn't happen then, then deselect the yellow cubes by clicking the background, it should hang. Again it doesn't always happen, and it doesn't always happen with the same steps; another one I've seen is: open blend, deselect currently select cubes, switch to the material properties tab, select green cubes, switch to the render properties tab. I'll try to play a bit with perf, I don't guarantee anything ^^'. EDIT: To be fair though, I see the same behavior on 2.82a; the hang I'm talking about is like a ~2s delay in selecting or deselecting the cubes.

Stefano Bonicatti commented

2020-05-30 21:41:53 +02:00

The hang during selection happens in source/blender/editors/space_view3d/view3d_view.c:1096, view3d_opengl_select() when it calls DRW_opengl_context_enable() -> DRW_opengl_context_enable_ex() -> BLI_ticket_mutex_lock(DST.gl_context_mutex).

What I'm seeing holding the lock is DRW_render_to_image and the strack trace is:

[...]
- 22 0x00005555583692ac in GPU_shader_create_ex (vertexcode=<optimized out>, fragcode=<optimized out>, geocode=<optimized out>, libcode=<optimized out>, libcode@entry=0x0, defines=0x7fffba7ea288 "#define EEVEE_ENGINE\n#define MAX_PROBE 128\n#define MAX_GRID 64\n#define MAX_PLANAR 16\n#define MAX_LIGHT 128\n#define MAX_SHADOW 128\n#define MAX_SHADOW_CUBE (128 - 4 * 8)\n#define MAX_SHADOW_CASCADE 8\n#de"..., tf_type=tf_type@entry=GPU_SHADER_TFB_NONE, tf_names=<optimized out>, tf_count=<optimized out>, shname=<optimized out>) at /home/smjert/Development/blender-git/blender/source/blender/gpu/intern/gpu_shader.c:553
- 23 0x00005555583698e2 in GPU_shader_create (vertexcode=<optimized out>, fragcode=<optimized out>, geocode=<optimized out>, libcode=libcode@entry=0x0, defines=<optimized out>, shname=shname@entry=0x555558b65820 <__func__.0> "GPU_material_compile") at /home/smjert/Development/blender-git/blender/source/blender/gpu/intern/gpu_shader.c:295
- 24 0x000055555835871a in GPU_pass_compile (pass=0x7fffa9660488, shname=shname@entry=0x555558b65820 <__func__.0> "GPU_material_compile") at /home/smjert/Development/blender-git/blender/source/blender/gpu/intern/gpu_codegen.c:1216
- 25 0x0000555558363cf4 in GPU_material_compile (mat=mat@entry=0x7fffba7f15a8) at /home/smjert/Development/blender-git/blender/source/blender/gpu/intern/gpu_material.c:755
- 26 0x000055555663ceb0 in drw_deferred_shader_add (deferred=true, mat=0x7fffba7f15a8) at /home/smjert/Development/blender-git/blender/source/blender/draw/intern/draw_manager_shader.c:193
- 27 DRW_shader_create_from_material (scene=<optimized out>, scene@entry=0x7fffba7d5008, ma=ma@entry=0x7fffba804008, engine_type=engine_type@entry=0x55555984fa40 <DRW_engine_viewport_eevee_type>, options=options@entry=1, is_volume_shader=is_volume_shader@entry=false, vert=<optimized out>, geom=0x0, frag_lib=0x7fffa96f8688 "#define COMMON_VIEW_LIB\n#define DRW_RESOURCE_CHUNK_LEN 512\n\n/* keep in sync with DRWManager.view_data */\nlayout(std140) uniform viewBlock\n{\n  /* Same order as DRWViewportMatrixType */\n  mat4 ViewProje"..., defines=0x7fffba80f8c8 "#define EEVEE_ENGINE\n#define MAX_PROBE 128\n#define MAX_GRID 64\n#define MAX_PLANAR 16\n#define MAX_LIGHT 128\n#define MAX_SHADOW 128\n#define MAX_SHADOW_CUBE (128 - 4 * 8)\n#define MAX_SHADOW_CASCADE 8\n#de"..., deferred=true) at /home/smjert/Development/blender-git/blender/source/blender/draw/intern/draw_manager_shader.c:471
- 28 0x00005555565f14f1 in EEVEE_material_mesh_get (scene=scene@entry=0x7fffba7d5008, ma=ma@entry=0x7fffba804008, UNUSED_vedata=UNUSED_vedata@entry=0x7fffa6bce288, use_blend=use_blend@entry=false, use_refract=use_refract@entry=false) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_materials.c:861
- 29 0x00005555565f31e2 in material_opaque (holdout=<optimized out>, shgrps=0x7fffad53c4a0, gpumat_depth=<optimized out>, gpumat=0x7fffad53c490, vedata=0x7fffa6bce288, sldata=0x7fffba7bfa88, material_hash=0x7fffba7c7368, ma=0x7fffba804008) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_materials.c:1446
- 30 EEVEE_materials_cache_populate (vedata=vedata@entry=0x7fffa6bce288, sldata=sldata@entry=0x7fffba7bfa88, ob=ob@entry=0x7fffba7a5408, cast_shadow=cast_shadow@entry=0x7fffad53c67f) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_materials.c:2042
- 31 0x00005555565f6c0b in EEVEE_render_cache (vedata=vedata@entry=0x7fffa6bce288, ob=ob@entry=0x7fffba7a5408, engine=engine@entry=0x7fffba7bf008, depsgraph=depsgraph@entry=0x7fffba7cb008) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_render.c:211
- 32 0x00005555565dba69 in DRW_render_object_iter (vedata=vedata@entry=0x7fffa6bce288, engine=engine@entry=0x7fffba7bf008, depsgraph=0x7fffba7cb008, callback=0x5555565f6aa0 <EEVEE_render_cache>) at /home/smjert/Development/blender-git/blender/source/blender/draw/intern/draw_manager.c:1879
- 33 0x00005555565e7866 in eevee_render_to_image (vedata=0x7fffa6bce288, engine=0x7fffba7bf008, render_layer=0x7fffba784068, rect=0x7fffad53cdc0) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_engine.c:432
- 34 0x00005555565dcca0 in DRW_render_to_image (engine=0x7fffba7bf008, depsgraph=0x7fffad53cdc0) at /home/smjert/Development/blender-git/blender/source/blender/draw/intern/draw_manager.c:1819
- 35 0x0000555557ed3f2c in RE_engine_render (re=0x7fffba78a808, do_all=do_all@entry=0) at /home/smjert/Development/blender-git/blender/source/blender/render/intern/source/external_engine.c:872
#36 0x0000555557edfae0 in do_render_3d (re=<optimized out>) at /home/smjert/Development/blender-git/blender/source/blender/render/intern/source/pipeline.c:1137
[...]
- 65 0x0000555557276629 in shader_preview_startjob (customdata=0x414d, customdata@entry=0x7fffba780008, stop=<optimized out>, do_update=0x7fffba780008, do_update@entry=0x555557276277 <shader_preview_render+455>) at /home/smjert/Development/blender-git/blender/source/blender/editors/render/render_preview.c:946
- 66 0x0000555557276af8 in icon_preview_startjob (customdata=0x7fffba780008, stop=<optimized out>, do_update=0x555557276277 <shader_preview_render+455>) at /home/smjert/Development/blender-git/blender/source/blender/editors/render/render_preview.c:1165
- 67 0x0000555557276d83 in common_preview_startjob (UNUSED_progress=<optimized out>, do_update=0x7fffba780008, stop=0x7fffba3c2484, customdata=0x7fffba780008) at /home/smjert/Development/blender-git/blender/source/blender/editors/render/render_preview.c:1273
- 68 icon_preview_startjob_all_sizes (customdata=0x7fffaf9fb748, stop=0x7fffba3c2484, do_update=0x7fffba780008, progress=<optimized out>) at /home/smjert/Development/blender-git/blender/source/blender/editors/render/render_preview.c:1273
#69 0x00005555565007c2 in do_job_thread (job_v=0x7fffba3c2408) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm_jobs.c:397
[...]

So it seems Eevee is updating the material preview?
This is even more apparent if one expands the actual preview in the Material Properties tab.

When collapsed it doesn't always update it, it calls it sparingly, but sometimes it takes more than "usual" and so it blocks the selection; expanding the Preview section will always update the preview instead.

I don't know if it's wanted but maybe it shouldn't update the preview if the Preview section is collapsed?

This is the only hang/freeze I noticed.

The hang during selection happens in source/blender/editors/space_view3d/view3d_view.c:1096, view3d_opengl_select() when it calls DRW_opengl_context_enable() -> DRW_opengl_context_enable_ex() -> BLI_ticket_mutex_lock(DST.gl_context_mutex). What I'm seeing holding the lock is DRW_render_to_image and the strack trace is: ``` [...] - 22 0x00005555583692ac in GPU_shader_create_ex (vertexcode=<optimized out>, fragcode=<optimized out>, geocode=<optimized out>, libcode=<optimized out>, libcode@entry=0x0, defines=0x7fffba7ea288 "#define EEVEE_ENGINE\n#define MAX_PROBE 128\n#define MAX_GRID 64\n#define MAX_PLANAR 16\n#define MAX_LIGHT 128\n#define MAX_SHADOW 128\n#define MAX_SHADOW_CUBE (128 - 4 * 8)\n#define MAX_SHADOW_CASCADE 8\n#de"..., tf_type=tf_type@entry=GPU_SHADER_TFB_NONE, tf_names=<optimized out>, tf_count=<optimized out>, shname=<optimized out>) at /home/smjert/Development/blender-git/blender/source/blender/gpu/intern/gpu_shader.c:553 - 23 0x00005555583698e2 in GPU_shader_create (vertexcode=<optimized out>, fragcode=<optimized out>, geocode=<optimized out>, libcode=libcode@entry=0x0, defines=<optimized out>, shname=shname@entry=0x555558b65820 <__func__.0> "GPU_material_compile") at /home/smjert/Development/blender-git/blender/source/blender/gpu/intern/gpu_shader.c:295 - 24 0x000055555835871a in GPU_pass_compile (pass=0x7fffa9660488, shname=shname@entry=0x555558b65820 <__func__.0> "GPU_material_compile") at /home/smjert/Development/blender-git/blender/source/blender/gpu/intern/gpu_codegen.c:1216 - 25 0x0000555558363cf4 in GPU_material_compile (mat=mat@entry=0x7fffba7f15a8) at /home/smjert/Development/blender-git/blender/source/blender/gpu/intern/gpu_material.c:755 - 26 0x000055555663ceb0 in drw_deferred_shader_add (deferred=true, mat=0x7fffba7f15a8) at /home/smjert/Development/blender-git/blender/source/blender/draw/intern/draw_manager_shader.c:193 - 27 DRW_shader_create_from_material (scene=<optimized out>, scene@entry=0x7fffba7d5008, ma=ma@entry=0x7fffba804008, engine_type=engine_type@entry=0x55555984fa40 <DRW_engine_viewport_eevee_type>, options=options@entry=1, is_volume_shader=is_volume_shader@entry=false, vert=<optimized out>, geom=0x0, frag_lib=0x7fffa96f8688 "#define COMMON_VIEW_LIB\n#define DRW_RESOURCE_CHUNK_LEN 512\n\n/* keep in sync with DRWManager.view_data */\nlayout(std140) uniform viewBlock\n{\n /* Same order as DRWViewportMatrixType */\n mat4 ViewProje"..., defines=0x7fffba80f8c8 "#define EEVEE_ENGINE\n#define MAX_PROBE 128\n#define MAX_GRID 64\n#define MAX_PLANAR 16\n#define MAX_LIGHT 128\n#define MAX_SHADOW 128\n#define MAX_SHADOW_CUBE (128 - 4 * 8)\n#define MAX_SHADOW_CASCADE 8\n#de"..., deferred=true) at /home/smjert/Development/blender-git/blender/source/blender/draw/intern/draw_manager_shader.c:471 - 28 0x00005555565f14f1 in EEVEE_material_mesh_get (scene=scene@entry=0x7fffba7d5008, ma=ma@entry=0x7fffba804008, UNUSED_vedata=UNUSED_vedata@entry=0x7fffa6bce288, use_blend=use_blend@entry=false, use_refract=use_refract@entry=false) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_materials.c:861 - 29 0x00005555565f31e2 in material_opaque (holdout=<optimized out>, shgrps=0x7fffad53c4a0, gpumat_depth=<optimized out>, gpumat=0x7fffad53c490, vedata=0x7fffa6bce288, sldata=0x7fffba7bfa88, material_hash=0x7fffba7c7368, ma=0x7fffba804008) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_materials.c:1446 - 30 EEVEE_materials_cache_populate (vedata=vedata@entry=0x7fffa6bce288, sldata=sldata@entry=0x7fffba7bfa88, ob=ob@entry=0x7fffba7a5408, cast_shadow=cast_shadow@entry=0x7fffad53c67f) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_materials.c:2042 - 31 0x00005555565f6c0b in EEVEE_render_cache (vedata=vedata@entry=0x7fffa6bce288, ob=ob@entry=0x7fffba7a5408, engine=engine@entry=0x7fffba7bf008, depsgraph=depsgraph@entry=0x7fffba7cb008) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_render.c:211 - 32 0x00005555565dba69 in DRW_render_object_iter (vedata=vedata@entry=0x7fffa6bce288, engine=engine@entry=0x7fffba7bf008, depsgraph=0x7fffba7cb008, callback=0x5555565f6aa0 <EEVEE_render_cache>) at /home/smjert/Development/blender-git/blender/source/blender/draw/intern/draw_manager.c:1879 - 33 0x00005555565e7866 in eevee_render_to_image (vedata=0x7fffa6bce288, engine=0x7fffba7bf008, render_layer=0x7fffba784068, rect=0x7fffad53cdc0) at /home/smjert/Development/blender-git/blender/source/blender/draw/engines/eevee/eevee_engine.c:432 - 34 0x00005555565dcca0 in DRW_render_to_image (engine=0x7fffba7bf008, depsgraph=0x7fffad53cdc0) at /home/smjert/Development/blender-git/blender/source/blender/draw/intern/draw_manager.c:1819 - 35 0x0000555557ed3f2c in RE_engine_render (re=0x7fffba78a808, do_all=do_all@entry=0) at /home/smjert/Development/blender-git/blender/source/blender/render/intern/source/external_engine.c:872 #36 0x0000555557edfae0 in do_render_3d (re=<optimized out>) at /home/smjert/Development/blender-git/blender/source/blender/render/intern/source/pipeline.c:1137 [...] - 65 0x0000555557276629 in shader_preview_startjob (customdata=0x414d, customdata@entry=0x7fffba780008, stop=<optimized out>, do_update=0x7fffba780008, do_update@entry=0x555557276277 <shader_preview_render+455>) at /home/smjert/Development/blender-git/blender/source/blender/editors/render/render_preview.c:946 - 66 0x0000555557276af8 in icon_preview_startjob (customdata=0x7fffba780008, stop=<optimized out>, do_update=0x555557276277 <shader_preview_render+455>) at /home/smjert/Development/blender-git/blender/source/blender/editors/render/render_preview.c:1165 - 67 0x0000555557276d83 in common_preview_startjob (UNUSED_progress=<optimized out>, do_update=0x7fffba780008, stop=0x7fffba3c2484, customdata=0x7fffba780008) at /home/smjert/Development/blender-git/blender/source/blender/editors/render/render_preview.c:1273 - 68 icon_preview_startjob_all_sizes (customdata=0x7fffaf9fb748, stop=0x7fffba3c2484, do_update=0x7fffba780008, progress=<optimized out>) at /home/smjert/Development/blender-git/blender/source/blender/editors/render/render_preview.c:1273 #69 0x00005555565007c2 in do_job_thread (job_v=0x7fffba3c2408) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm_jobs.c:397 [...] ``` So it seems Eevee is updating the material preview? This is even more apparent if one expands the actual preview in the Material Properties tab. When collapsed it doesn't always update it, it calls it sparingly, but sometimes it takes more than "usual" and so it blocks the selection; expanding the Preview section will always update the preview instead. I don't know if it's wanted but maybe it shouldn't update the preview if the Preview section is collapsed? This is the only hang/freeze I noticed.

Richard Antalik commented

2020-11-26 22:24:11 +01:00

Added subscriber: @iss