Intel UHD 620: Blender crashes at modifying material properties #77346

New Issue

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Intel(R) UHD Graphics 620 Intel 4.5.0 - Build 26.20.100.6859
Also 27.20.100.8280

Blender Version
Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-06-03 18:45, hash: b94ab93dfb
Worked: version: 2.83

Short description of error
After opening blender with default general template, tried changing the base color of material and blender crashes.
blender_system_info.txt, {F8640691, layout = inline}
blender_debug_output.txt
blender.crash.txt

Exact steps for others to reproduce the error

Open blender
Select general template from splash screen.
without selecting any other tool or option, go straight to materials tab, and try changing the base color 1 or 2 times. (default material : principled bsdf)
most likely 2nd time change is causing blender crash.

after crash reopen blender and this time it crashes even if we just click on base color field.

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: Intel(R) UHD Graphics 620 Intel 4.5.0 - Build 26.20.100.6859 Also 27.20.100.8280 **Blender Version** Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-06-03 18:45, hash: `b94ab93dfb` Worked: version: 2.83 **Short description of error** After opening blender with default general template, tried changing the base color of material and blender crashes. [blender_system_info.txt](https://archive.blender.org/developer/F8603488/blender_system_info.txt), {[F8640691](https://archive.blender.org/developer/F8640691/blender_system_info.txt), layout = inline} [blender_debug_output.txt](https://archive.blender.org/developer/F8603487/blender_debug_output.txt) [blender.crash.txt](https://archive.blender.org/developer/F8640615/blender.crash.txt) **Exact steps for others to reproduce the error** - Open blender - Select general template from splash screen. - without selecting any other tool or option, go straight to materials tab, and try changing the base color 1 or 2 times. (default material : principled bsdf) most likely 2nd time change is causing blender crash. after crash reopen blender and this time it crashes even if we just click on base color field.

Added subscriber: @(Deleted)

#78889 was marked as duplicate of this issue

#78817 was marked as duplicate of this issue

#78458 was marked as duplicate of this issue

#78095 was marked as duplicate of this issue

#78344 was marked as duplicate of this issue

#78212 was marked as duplicate of this issue

#77748 was marked as duplicate of this issue

#78196 was marked as duplicate of this issue

Added subscriber: @Alaska

Changed status from 'Needs Triage' to: 'Needs User Info'

The recent builds of 2.90.0 have been quite unstable based on my personal experience. However, I'm unable to reproduce this issue on Linux with a GTX 1050Ti.

I was able to reproduce this on a computer I was using earlier today with Intel UHD Graphics 630 on Windows 10. But I won't have access to this computer for another 20 or so hours, so I can't confirm this case.

Are you able to try to things:

Make sure your Intel GPU drivers are up to date.
Are you able to navigate to the Blender installation directory and run it with the file blender_debug_log.cmd then get Blender to crash. A file explorer should open with two text files, upload those two files to here.

The recent builds of 2.90.0 have been quite unstable based on my personal experience. However, I'm unable to reproduce this issue on Linux with a GTX 1050Ti. I was able to reproduce this on a computer I was using earlier today with Intel UHD Graphics 630 on Windows 10. But I won't have access to this computer for another 20 or so hours, so I can't confirm this case. Are you able to try to things: 1. Make sure your Intel GPU drivers are up to date. 2. Are you able to navigate to the Blender installation directory and run it with the file `blender_debug_log.cmd` then get Blender to crash. A file explorer should open with two text files, upload those two files to here.

This issue may have been fixed in recent commits to master. Are you able to test with the latest Blender 2.90.0 build? http://builder.blender.org/

In #77346#947448, @Alaska wrote:
This issue may have been fixed in recent commits to master. Are you able to test with the latest Blender 2.90.0 build? http://builder.blender.org/

Today I checked using latest build but still the problem remains. My drivers are up to date. last week it was fine but suddenly this problem popped up.
I have checked changing color in grease pencil and there it works fine.

> In #77346#947448, @Alaska wrote: > This issue may have been fixed in recent commits to master. Are you able to test with the latest Blender 2.90.0 build? http://builder.blender.org/ Today I checked using latest build but still the problem remains. My drivers are up to date. last week it was fine but suddenly this problem popped up. I have checked changing color in grease pencil and there it works fine.

In #77346#944287, @Alaska wrote:
The recent builds of 2.90.0 have been quite unstable based on my personal experience. However, I'm unable to reproduce this issue on Linux with a GTX 1050Ti.

I was able to reproduce this on a computer I was using earlier today with Intel UHD Graphics 630 on Windows 10. But I won't have access to this computer for another 20 or so hours, so I can't confirm this case.

Are you able to try to things:

Make sure your Intel GPU drivers are up to date.

Are you able to navigate to the Blender installation directory and run it with the file blender_debug_log.cmd then get Blender to crash. A file explorer should open with two text files, upload those two files to here.

here attached debug logs.

blender_system_info.txt

blender_debug_output.txt

> In #77346#944287, @Alaska wrote: > The recent builds of 2.90.0 have been quite unstable based on my personal experience. However, I'm unable to reproduce this issue on Linux with a GTX 1050Ti. > > I was able to reproduce this on a computer I was using earlier today with Intel UHD Graphics 630 on Windows 10. But I won't have access to this computer for another 20 or so hours, so I can't confirm this case. > > Are you able to try to things: > 1. Make sure your Intel GPU drivers are up to date. > 2. Are you able to navigate to the Blender installation directory and run it with the file `blender_debug_log.cmd` then get Blender to crash. A file explorer should open with two text files, upload those two files to here. here attached debug logs. [blender_system_info.txt](https://archive.blender.org/developer/F8603488/blender_system_info.txt) [blender_debug_output.txt](https://archive.blender.org/developer/F8603487/blender_debug_output.txt)

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

I don't really know where to progress from here. Will need the developers to investigate.

Added subscriber: @mano-wii

Changed status from 'Needs Developer To Reproduce' to: 'Needs User Info'

@pattamp, you forgot to include information about a version of Blender that works.
Did you try 2.83 or 2.82?

@pattamp, you forgot to include information about a version of Blender that works. Did you try 2.83 or 2.82?

In #77346#951942, @mano-wii wrote:
@pattamp, you forgot to include information about a version of Blender that works.
Did you try 2.83 or 2.82?

yes I have used 2.83 and its working fine without any issue.

> In #77346#951942, @mano-wii wrote: > @pattamp, you forgot to include information about a version of Blender that works. > Did you try 2.83 or 2.82? yes I have used 2.83 and its working fine without any issue.

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Added subscriber: @iss

@pattamp Could you re-trigger bug and upload crash.txt file mentioned at the end of blender_debug_output.txt?

Should be C:\Users\xx\AppData\Local\Temp\blender.crash.txt in your case.

@pattamp Could you re-trigger bug and upload `crash.txt` file mentioned at the end of `blender_debug_output.txt`? Should be `C:\Users\xx\AppData\Local\Temp\blender.crash.txt` in your case.

Added subscriber: @ankitm

My drivers are up to date.

https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789
This page says that latest drivers are 27.x, not 23.x

> My drivers are up to date. https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789 This page says that latest drivers are 27.x, not 23.x

Changed status from 'Needs Developer To Reproduce' to: 'Needs User Info'

In #77346#964197, @ankitm wrote:

My drivers are up to date.

https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789
This page says that latest drivers are 27.x, not 23.x

I have tried installing this version 27.x but it is not validated for my system

my current driver version is updated to

attached crash report
blender.crash.txt

> In #77346#964197, @ankitm wrote: >> My drivers are up to date. > https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789 > This page says that latest drivers are 27.x, not 23.x I have tried installing this version 27.x but it is not validated for my system ![image.png](https://archive.blender.org/developer/F8640607/image.png) my current driver version is updated to ![image.png](https://archive.blender.org/developer/F8640610/image.png) attached crash report [blender.crash.txt](https://archive.blender.org/developer/F8640615/blender.crash.txt)

In #77346#964197, @ankitm wrote:

My drivers are up to date.

https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789
This page says that latest drivers are 27.x, not 23.x

BTW earlier attached blender_system_info.txt file already shows ver 26.x for driver.
Ver 23 was when i first noticed the crash, later updated the driver to ver 26 and still had the crash.

> In #77346#964197, @ankitm wrote: >> My drivers are up to date. > https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789 > This page says that latest drivers are 27.x, not 23.x BTW earlier attached blender_system_info.txt file already shows ver 26.x for driver. Ver 23 was when i first noticed the crash, later updated the driver to ver 26 and still had the crash.

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Added subscribers: @Binafa, @grosgood

Added subscribers: @raindrops, @lichtwerk, @JacquesLucke

Added subscribers: @nerjal, @HooglyBoogly

Added subscriber: @EAW

In #77346#964197, @ankitm wrote:

My drivers are up to date.

https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789
This page says that latest drivers are 27.x, not 23.x

For Intel drivers on Windows, only pay attention to the last 4 digits.

https://www.intel.com/content/www/us/en/support/articles/000005654/graphics.html

> In #77346#964197, @ankitm wrote: >> My drivers are up to date. > https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789 > This page says that latest drivers are 27.x, not 23.x For Intel drivers on Windows, only pay attention to the last 4 digits. https://www.intel.com/content/www/us/en/support/articles/000005654/graphics.html

Added subscriber: @xxxdakevingame

Added subscriber: @Quesbe

Added subscriber: @Jeroen-Bakker

I was able to reproduce this one. Strange enough you don't need to have EEVEE active.
system-info.txt
Will check tomorrow with latest Intel Driver and debug builds

I was able to reproduce this one. Strange enough you don't need to have EEVEE active. [system-info.txt](https://archive.blender.org/developer/F8653821/system-info.txt) Will check tomorrow with latest Intel Driver and debug builds

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

Added subscriber: @mikon117

I confirm on mac (macbook pro 13 "2019) I am using version 2.83.1 and it is truly a disaster, the 2.82 was much better in terms of stability. The program crashes even in the transition from solid mode to material preview. times I don't understand why they are much longer and even in the transition from uv editing to shading the program crashes. Obviously I'm talking about light files that normally in my pc have never given problems.

blender.exe         :0x00007FF6C83E1880  bli_windows_system_backtrace_stack_thread C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:233
blender.exe         :0x00007FF6C83E0900  BLI_windows_system_backtrace_stack C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:320
blender.exe         :0x00007FF6C83E02B0  BLI_system_backtrace C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:383
blender.exe         :0x00007FF6C720E0A0  EEVEE_material_get C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_shaders.c:761
blender.exe         :0x00007FF6C71D4F70  EEVEE_lightprobes_cache_init C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_lightprobes.c:341
blender.exe         :0x00007FF6C71E4990  EEVEE_render_cache_init C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_render.c:180
blender.exe         :0x00007FF6C71BA370  eevee_render_to_image C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_engine.c:521
blender.exe         :0x00007FF6C7150EA0  DRW_render_to_image C:\blender-git\blender\source\blender\draw\intern\draw_manager.c:1827
blender.exe         :0x00007FF6C8263BE0  RE_engine_render C:\blender-git\blender\source\blender\render\intern\source\external_engine.c:880
blender.exe         :0x00007FF6C8279010  do_render_3d C:\blender-git\blender\source\blender\render\intern\source\pipeline.c:1138
blender.exe         :0x00007FF6C8273830  RE_PreviewRender C:\blender-git\blender\source\blender\render\intern\source\pipeline.c:2687
blender.exe         :0x00007FF6C818FF20  shader_preview_render C:\blender-git\blender\source\blender\editors\render\render_preview.c:911
blender.exe         :0x00007FF6C81904B0  shader_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:949
blender.exe         :0x00007FF6C818D7F0  icon_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:1169
blender.exe         :0x00007FF6C818C640  common_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:1188
blender.exe         :0x00007FF6C818DDB0  icon_preview_startjob_all_sizes C:\blender-git\blender\source\blender\editors\render\render_preview.c:1274
blender.exe         :0x00007FF6C697CE80  do_job_thread C:\blender-git\blender\source\blender\windowmanager\intern\wm_jobs.c:398
blender.exe         :0x00007FF6C83E40B0  tslot_thread_start C:\blender-git\blender\source\blender\blenlib\intern\threads.c:222
blender.exe         :0x00007FF6C86CF120  _ptw32_threadStart
ucrtbased.dll       :0x00007FF8A8F95340  register_onexit_function
KERNEL32.DLL        :0x00007FF8C8074020  BaseThreadInitThunk
ntdll.dll           :0x00007FF8CA2A3670  RtlUserThreadStart

During the rendering of the material preview it crashes. The GLSL shader must be in compiled state, but is in queued state.

``` blender.exe :0x00007FF6C83E1880 bli_windows_system_backtrace_stack_thread C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:233 blender.exe :0x00007FF6C83E0900 BLI_windows_system_backtrace_stack C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:320 blender.exe :0x00007FF6C83E02B0 BLI_system_backtrace C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:383 blender.exe :0x00007FF6C720E0A0 EEVEE_material_get C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_shaders.c:761 blender.exe :0x00007FF6C71D4F70 EEVEE_lightprobes_cache_init C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_lightprobes.c:341 blender.exe :0x00007FF6C71E4990 EEVEE_render_cache_init C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_render.c:180 blender.exe :0x00007FF6C71BA370 eevee_render_to_image C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_engine.c:521 blender.exe :0x00007FF6C7150EA0 DRW_render_to_image C:\blender-git\blender\source\blender\draw\intern\draw_manager.c:1827 blender.exe :0x00007FF6C8263BE0 RE_engine_render C:\blender-git\blender\source\blender\render\intern\source\external_engine.c:880 blender.exe :0x00007FF6C8279010 do_render_3d C:\blender-git\blender\source\blender\render\intern\source\pipeline.c:1138 blender.exe :0x00007FF6C8273830 RE_PreviewRender C:\blender-git\blender\source\blender\render\intern\source\pipeline.c:2687 blender.exe :0x00007FF6C818FF20 shader_preview_render C:\blender-git\blender\source\blender\editors\render\render_preview.c:911 blender.exe :0x00007FF6C81904B0 shader_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:949 blender.exe :0x00007FF6C818D7F0 icon_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:1169 blender.exe :0x00007FF6C818C640 common_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:1188 blender.exe :0x00007FF6C818DDB0 icon_preview_startjob_all_sizes C:\blender-git\blender\source\blender\editors\render\render_preview.c:1274 blender.exe :0x00007FF6C697CE80 do_job_thread C:\blender-git\blender\source\blender\windowmanager\intern\wm_jobs.c:398 blender.exe :0x00007FF6C83E40B0 tslot_thread_start C:\blender-git\blender\source\blender\blenlib\intern\threads.c:222 blender.exe :0x00007FF6C86CF120 _ptw32_threadStart ucrtbased.dll :0x00007FF8A8F95340 register_onexit_function KERNEL32.DLL :0x00007FF8C8074020 BaseThreadInitThunk ntdll.dll :0x00007FF8CA2A3670 RtlUserThreadStart ``` During the rendering of the material preview it crashes. The GLSL shader must be in compiled state, but is in queued state.

Issue is related to a work around that we added for this specific configuration. GG.context_local_shaders_workaround. The work around would always use the main thread for loading shaders. When doing preview renders the compilation happens in the caller thread, but is stored in a binary. This binary is loaded as a shader when the caller is part of the main thread.

Due to recent refactorings it is assumed that the caller always returns a valid shader so its interface can be introspected, what isn't the case.

I tested by disabling the workaround and it seems to be working (perhaps it got fixed in the driver in the mean time). But as the work around is also activated for other IGPUs on Windows it is hard to say that all platforms are currently working.

Regression introduced by {b18c2a3c413b7741b2a854b7bd25721352be2589}

@fclem: any advice how to fix this? Issue is that the shaders are needed for the interface, but the shader is stored in binary form. and the default shader is loaded, which also is loaded in binary form. Issue can be reproduced by

diff --git a/source/blender/gpu/intern/gpu_extensions.c b/source/blender/gpu/intern/gpu_extensions.c
index 335dabdcb01..8948aef20e3 100644
--- a/source/blender/gpu/intern/gpu_extensions.c
+++ b/source/blender/gpu/intern/gpu_extensions.c
@@ -224,7 +224,7 @@ bool GPU_unused_fb_slot_workaround(void)
 
 bool GPU_context_local_shaders_workaround(void)
 {
-  return GG.context_local_shaders_workaround;
+  return true;  // GG.context_local_shaders_workaround;
 }
 
 bool GPU_texture_copy_workaround(void)

Issue is related to a work around that we added for this specific configuration. `GG.context_local_shaders_workaround`. The work around would always use the main thread for loading shaders. When doing preview renders the compilation happens in the caller thread, but is stored in a binary. This binary is loaded as a shader when the caller is part of the main thread. Due to recent refactorings it is assumed that the caller always returns a valid shader so its interface can be introspected, what isn't the case. I tested by disabling the workaround and it seems to be working (perhaps it got fixed in the driver in the mean time). But as the work around is also activated for other IGPUs on Windows it is hard to say that all platforms are currently working. Regression introduced by {b18c2a3c413b7741b2a854b7bd25721352be2589} @fclem: any advice how to fix this? Issue is that the shaders are needed for the interface, but the shader is stored in binary form. and the default shader is loaded, which also is loaded in binary form. Issue can be reproduced by ``` diff --git a/source/blender/gpu/intern/gpu_extensions.c b/source/blender/gpu/intern/gpu_extensions.c index 335dabdcb01..8948aef20e3 100644 --- a/source/blender/gpu/intern/gpu_extensions.c +++ b/source/blender/gpu/intern/gpu_extensions.c @@ -224,7 +224,7 @@ bool GPU_unused_fb_slot_workaround(void) bool GPU_context_local_shaders_workaround(void) { - return GG.context_local_shaders_workaround; + return true; // GG.context_local_shaders_workaround; } bool GPU_texture_copy_workaround(void) ```

Added subscriber: @fclem

We could change that workarround to simply compile the shaders in single thread.
Even in multithreaded, the interface remains locked during the compilation of shaders on these GPUs and it is possible that internally the driver already compiles in multithreaded.

We could change that workarround to simply compile the shaders in single thread. Even in multithreaded, the interface remains locked during the compilation of shaders on these GPUs and it is possible that internally the driver already compiles in multithreaded.

Added subscriber: @elkoled-1

Added subscriber: @ArthurPholax

Can this be somehow related with issues in #77944 ?
In my case Blender 2.9 also crashes.

Can this be somehow related with issues in #77944 ? In my case Blender 2.9 also crashes.

@Jeroen-Bakker I'm ok with removing this workaround only for intel HD6xx.

index ab55fcfb1e0..2a9e9072d2a 100644
    - a/source/blender/gpu/intern/gpu_extensions.c
+++ b/source/blender/gpu/intern/gpu_extensions.c
@@ -326,7 +326,6 @@ void gpu_extensions_init(void)

GG.depth_blitting_workaround = true;
GG.unused_fb_slot_workaround = true;
GG.texture_copy_workaround = true;

- GG.context_local_shaders_workaround = GLEW_ARB_get_program_binary;

}

/* Special fix for theses specific GPUs.

@@ -334,7 +333,6 @@ void gpu_extensions_init(void)

if (GPU_type_matches(GPU_DEVICE_INTEL, GPU_OS_WIN, GPU_DRIVER_OFFICIAL) &&
(strstr(renderer, "HD Graphics 620") || strstr(renderer, "HD Graphics 630"))) {
GG.mip_render_workaround = true;

- GG.context_local_shaders_workaround = GLEW_ARB_get_program_binary;

}

/* df/dy calculation factors, those are dependent on driver */

Any objection?

@Jeroen-Bakker I'm ok with removing this workaround only for intel HD6xx. ```diff --git a/source/blender/gpu/intern/gpu_extensions.c b/source/blender/gpu/intern/gpu_extensions.c index ab55fcfb1e0..2a9e9072d2a 100644 - a/source/blender/gpu/intern/gpu_extensions.c +++ b/source/blender/gpu/intern/gpu_extensions.c @@ -326,7 +326,6 @@ void gpu_extensions_init(void) ``` GG.depth_blitting_workaround = true; GG.unused_fb_slot_workaround = true; GG.texture_copy_workaround = true; ``` - GG.context_local_shaders_workaround = GLEW_ARB_get_program_binary; ``` } ``` ``` /* Special fix for theses specific GPUs. ``` @@ -334,7 +333,6 @@ void gpu_extensions_init(void) ``` if (GPU_type_matches(GPU_DEVICE_INTEL, GPU_OS_WIN, GPU_DRIVER_OFFICIAL) && (strstr(renderer, "HD Graphics 620") || strstr(renderer, "HD Graphics 630"))) { GG.mip_render_workaround = true; ``` - GG.context_local_shaders_workaround = GLEW_ARB_get_program_binary; ``` } ``` ``` /* df/dy calculation factors, those are dependent on driver */ ``` ``` Any objection?

@fclem. we can remove it from 620/630, and temporarily remove it from the --gpu-enable-workarounds but still we need to fix the workaround for the other iGPUs.

@fclem. we can remove it from 620/630, and temporarily remove it from the `--gpu-enable-workarounds` but still we need to fix the workaround for the other iGPUs.

What a good solution, actually there are many of us who did not try the experience of version 2.90.0 again because of the fact that the application closes immediately when we do the steps mentioned above, all of you are making a very big effort and I congratulate you everyone at heart, I never regret having Blender. God bless you all.

This issue was referenced by 0f617cd67e

This issue was referenced by 0f617cd67ecdd5826a35c219f77f1481a63665a7

Added subscriber: @Mubinafa

Hello! I wanted to tell you that I am Juan Binafa (Binafa) and change the user Mubinafa, the fact is that I follow this thread, and I wanted to tell you that in this version "blender-2.90.0-afcb41a0aaaf-windows64" with graphics card "Intel (R) HD Graphics 620 updated "is working well on" fails to modify the properties of the material ", both in" EEVEE "which was where the problem occurred when starting the default application, until now this Alpha version" blender-2.90.0- afcb41a0aaaf-windows64 "works super well for problem" fails to modify material properties ". Thank you very much and it makes me very happy because you are working hard and you listen to us all when we see a problem in the software. Blessings.

Added subscriber: @Vaughn

Added subscribers: @hatinacat2000, @rjg

This issue was referenced by f7d38e2e64

This issue was referenced by f7d38e2e6426a21f4b91bedc0fe635aba4692ff2

Changed status from 'Confirmed' to: 'Resolved'

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Intel UHD 620: Blender crashes at modifying material properties #77346