Crash when changing preview render type. #104538

New Issue

Yassine-Amgarou · 2023-02-09T19:41:35+01:00

Yassine-Amgarou commented

2023-02-09 19:41:35 +01:00

System Information
Operating system: macOS-13.1-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Apple 4.1 Metal - 83

Blender Version
Broken: version: 3.4.1, branch: blender-v3.4-release, commit date: 2022-12-19 17:00, hash: rB55485cb379f7

Short description of error

*Blender crashes when i change preview render type, and it throws a crash message.

Exact steps for others to reproduce the error

Click preview in materials properties, then click on other preview render types.

**System Information** Operating system: macOS-13.1-arm64-arm-64bit 64 Bits Graphics card: Apple M1 Apple 4.1 Metal - 83 **Blender Version** Broken: version: 3.4.1, branch: blender-v3.4-release, commit date: 2022-12-19 17:00, hash: `rB55485cb379f7` **Short description of error** *Blender crashes when i change preview render type, and it throws a crash message. **Exact steps for others to reproduce the error** Click preview in materials properties, then click on other preview render types.

the preview crash.blend

819 KiB

Screenshot 2023-02-09 at 19.17.12.png

358 KiB

crash.rtf

49 KiB

Screenshot 2023-02-09 at 19.17.43.png

608 KiB

Yassine-Amgarou added the

labels 2023-02-09 19:41:35 +01:00

Iliya Katushenock commented

2023-02-09 19:49:33 +01:00

I see some potential duplicates/
#104242
#103652

I see some potential duplicates/ https://projects.blender.org/blender/blender/issues/104242 https://projects.blender.org/blender/blender/issues/103652

Yassine-Amgarou commented

2023-02-09 20:26:14 +01:00

what is the solution.

Iliya Katushenock commented

2023-02-09 20:30:53 +01:00

Sorry, i don't know, i can not reproduce or classified such issues/

Pratik Borhade commented

2023-02-10 06:45:41 +01:00

Hi, thanks for the report. Does it crash with viewport metal backend in 3.5 build?:

Crashed thread: 23

0   ???                           	       0x1355f1058 ???\
1   Blender                       	       0x1051bd5fc draw_call_single_do + 424\
2   Blender                       	       0x1051bce4c drw_draw_pass_ex + 1792\
3   Blender                       	       0x1051bc738 DRW_draw_pass + 32\
4   Blender                       	       0x1051eca68 EEVEE_shadows_draw_cubemap + 932\
5   Blender                       	       0x1051eb224 EEVEE_shadows_draw + 324\
6   Blender                       	       0x1051e3564 EEVEE_render_draw + 596\
7   Blender                       	       0x1051d6ed4 eevee_render_to_image + 716\
8   Blender                       	       0x1051b24f0 DRW_render_to_image + 360\
9   Blender                       	       0x105e0cb18 engine_render_view_layer(Render*, RenderEngine*, ViewLayer*, bool, bool) + 556\
10  Blender                       	       0x105e0c6c8 RE_engine_render + 860\
11  Blender                       	       0x105e12fb8 RE_PreviewRender + 128\
12  Blender                       	       0x106418750 shader_preview_render(ShaderPreview*, ID*, int, int) + 792\
13  Blender                       	       0x106418084 common_preview_startjob(void*, short*, short*, float*) + 356\
14  Blender                       	       0x10506144c do_job_thread + 40\
15  libsystem_pthread.dylib       	       0x18fbf106c _pthread_start + 148\
16  libsystem_pthread.dylib       	       0x18fbebe2c thread_start + 8\

I'm not able to confirm this in 3.5 build on Windows.
Does crash trigger instantly with any preview render type?

Hi, thanks for the report. Does it crash with viewport metal backend in 3.5 build?: ``` Crashed thread: 23 0 ??? 0x1355f1058 ???\ 1 Blender 0x1051bd5fc draw_call_single_do + 424\ 2 Blender 0x1051bce4c drw_draw_pass_ex + 1792\ 3 Blender 0x1051bc738 DRW_draw_pass + 32\ 4 Blender 0x1051eca68 EEVEE_shadows_draw_cubemap + 932\ 5 Blender 0x1051eb224 EEVEE_shadows_draw + 324\ 6 Blender 0x1051e3564 EEVEE_render_draw + 596\ 7 Blender 0x1051d6ed4 eevee_render_to_image + 716\ 8 Blender 0x1051b24f0 DRW_render_to_image + 360\ 9 Blender 0x105e0cb18 engine_render_view_layer(Render*, RenderEngine*, ViewLayer*, bool, bool) + 556\ 10 Blender 0x105e0c6c8 RE_engine_render + 860\ 11 Blender 0x105e12fb8 RE_PreviewRender + 128\ 12 Blender 0x106418750 shader_preview_render(ShaderPreview*, ID*, int, int) + 792\ 13 Blender 0x106418084 common_preview_startjob(void*, short*, short*, float*) + 356\ 14 Blender 0x10506144c do_job_thread + 40\ 15 libsystem_pthread.dylib 0x18fbf106c _pthread_start + 148\ 16 libsystem_pthread.dylib 0x18fbebe2c thread_start + 8\ ``` I'm not able to confirm this in 3.5 build on Windows. Does crash trigger instantly with any preview render type?

Pratik Borhade added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2023-02-10 06:46:27 +01:00

Yassine-Amgarou commented

2023-02-10 10:46:09 +01:00

hi, thank you for answering.
yes, it crashes instantly with any preview render type.

**but i tried the metal backend in build 3.5, and fortunately it didn't crash.

hi, thank you for answering. yes, it crashes instantly with any preview render type. **but i tried the metal backend in build 3.5, and fortunately it didn't crash.

Pratik Borhade commented

2023-02-10 11:26:08 +01:00

Thanks for the update.
Not sure about the policy when issue happens with one backend type.
@lichtwerk @Michael-Parkin-White-Apple, should we close this report? or do we need to keep it open until it gets fixed for OpenGL backend?

Thanks for the update. Not sure about the policy when issue happens with one backend type. @lichtwerk @Michael-Parkin-White-Apple, should we close this report? or do we need to keep it open until it gets fixed for OpenGL backend?

Michael Parkin-White commented

2023-02-10 11:40:32 +01:00

@PratikPB2123 Best for comment from @fclem or @jbakker on how best to handle this scenario. If the issue does not occur with the Metal backend then there is at least a workable version in place.

However, while OpenGL is still supported in builds, it is likely useful to track these issues and keep them open. The question is whether time is best spent on the legacy OpenGL support for macOS or continued work on Metal.

On a related note, it could perhaps be useful to tag issues with specific backend tokens, it may make it easier to filter issues in order to gain a better understanding of which issues are affecting which backend, as the backing implementations will have some fairly substantial differences.

Thanks!

@PratikPB2123 Best for comment from @fclem or @jbakker on how best to handle this scenario. If the issue does not occur with the Metal backend then there is at least a workable version in place. However, while OpenGL is still supported in builds, it is likely useful to track these issues and keep them open. The question is whether time is best spent on the legacy OpenGL support for macOS or continued work on Metal. On a related note, it could perhaps be useful to tag issues with specific backend tokens, it may make it easier to filter issues in order to gain a better understanding of which issues are affecting which backend, as the backing implementations will have some fairly substantial differences. Thanks!

Pratik Borhade commented

2023-02-10 11:48:06 +01:00

Thanks

@Jeroen-Bakker & @fclem can you comment on handling such cases?

it could perhaps be useful to tag issues with specific backend tokens, it may make it easier to filter issues

Yes, this sounds useful.

Thanks @Jeroen-Bakker & @fclem can you comment on handling such cases? ----- > it could perhaps be useful to tag issues with specific backend tokens, it may make it easier to filter issues Yes, this sounds useful.

Jeroen Bakker commented

2023-02-10 12:16:41 +01:00

I don't think we should spent a lot of time. Older iGPUs (HD4000) of Intel also had this issue. For 3.5 we have a work-around, and finding a work-around can be very time consuming.

I am wondering as it seems like a threading/context issue if we already have a workaround in place which we only need to activate. To test this we should start blender with --debug-gpu-force-workarounds and see if we can replicate the issue.

I am not able to reproduce the issue on my system.

I don't think we should spent a lot of time. Older iGPUs (HD4000) of Intel also had this issue. For 3.5 we have a work-around, and finding a work-around can be very time consuming. I am wondering as it seems like a threading/context issue if we already have a workaround in place which we only need to activate. To test this we should start blender with `--debug-gpu-force-workarounds` and see if we can replicate the issue. I am not able to reproduce the issue on my system.

Yassine-Amgarou commented

2023-02-10 15:11:32 +01:00

thank you guys for helping me.. you are the best.

Pratik Borhade added the

Platform

macOS

label 2023-04-28 07:47:49 +02:00

Pratik Borhade commented

2023-06-09 05:58:57 +02:00

I don't think we should spent a lot of time. Older iGPUs (HD4000) of Intel also had this issue.

@Jeroen-Bakker hi, closiing the report for now. This is already working in Metal backend.
Feel free to reopen if fixing the crash on OpenGL backend is still the priority of EEVEE module

> I don't think we should spent a lot of time. Older iGPUs (HD4000) of Intel also had this issue. @Jeroen-Bakker hi, closiing the report for now. This is already working in Metal backend. Feel free to reopen if fixing the crash on OpenGL backend is still the priority of EEVEE module

Pratik Borhade closed this issue

2023-06-09 05:58:59 +02:00

Blender Bot added

Status

Archived

and removed

Status

Needs Information from User

labels 2023-06-09 05:59:01 +02:00

Sign in to join this conversation.