Cycles Metal crash with simultaneous viewport and final render #94142

New Issue

Frederik De Bleser · 2021-12-16T09:42:47+01:00

2021-12-16 09:42:47 +01:00

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

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-12-15 00:57, hash: 67b657f07c
Worked: none (testing the new Metal renderer)

Short description of error
Blender crashes when using Cycles with Metal GPU in both viewport and renderer

Exact steps for others to reproduce the error

Open the attached file on a Mac with M1 processor
In Preferences > System, set Cycles Render Devices to Apple M1 (GPU).
Choose Rendered viewport shading
Press F12 to start the render. This will crash Blender.

human001-no-texture.blend

**System Information** Operating system: macOS-12.0.1-arm64-arm-64bit 64 Bits Graphics card: Apple M1 Apple 4.1 Metal - 76.1 **Blender Version** Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-12-15 00:57, hash: `67b657f07c` Worked: none (testing the new Metal renderer) **Short description of error** Blender crashes when using Cycles with Metal GPU in both viewport and renderer **Exact steps for others to reproduce the error** - Open the attached file on a Mac with M1 processor - In Preferences > System, set Cycles Render Devices to Apple M1 (GPU). - Choose Rendered viewport shading - Press F12 to start the render. This will crash Blender. [human001-no-texture.blend](https://archive.blender.org/developer/F12752831/human001-no-texture.blend)

Frederik De Bleser commented

2021-12-16 09:42:47 +01:00

Added subscriber: @FrederikDeBleser

Frederik De Bleser commented

2021-12-16 09:46:32 +01:00

I've attached the crash report:
2021-12-15-blender-crash-report.txt

I've attached the crash report: [2021-12-15-blender-crash-report.txt](https://archive.blender.org/developer/F12752847/2021-12-15-blender-crash-report.txt)

Jurgen Schraepen commented

2021-12-16 11:30:43 +01:00

Added subscriber: @JurgenS-4

Jurgen Schraepen commented

2021-12-16 11:30:43 +01:00

I have tested with this file and on my Mac mini M1 16 GB with the same build of blender, sometimes it works fine and other times it indeed chrashed.

Christian Baars commented

2021-12-16 13:24:46 +01:00

Added subscriber: @Staars

Christian Baars commented

2021-12-16 13:24:46 +01:00

More or less the same here.

When I wait for the viewport to finish the render completely (checking with start option --verbose 2 in the console), I can finish the first render and even finish a second render with that method. But when I want to close the render window the second time, I get a crash too.

More or less the same here. When I wait for the viewport to finish the render completely (checking with start option `--verbose 2` in the console), I can finish the first render and even finish a second render with that method. But when I want to close the render window the second time, I get a crash too.

Wade Lees commented

2021-12-16 15:42:42 +01:00

Added subscriber: @hatchli

Brecht Van Lommel commented

2021-12-16 18:50:41 +01:00

Added subscribers: @Michael-Jones, @brecht

Brecht Van Lommel commented

2021-12-16 18:50:41 +01:00

CC @michael_jones.

Caden Mitchell commented

2021-12-17 03:36:11 +01:00

Added subscriber: @Caden-Mitchell

Caden Mitchell commented

2021-12-17 03:36:11 +01:00

I also get a crash. With GPU only set in preferences and with CPU+GPU set. My scene also consumes ~30 GB of memory when rendering so maybe it is too advanced for the current Metal GPU render anyways? M1 16 GB RAM, macOS Monterey. It crashes on default cube, too.

Michael commented

2021-12-17 14:26:44 +01:00

Added subscriber: @michael64

Michael commented

2021-12-17 14:26:44 +01:00

The render on M1 with cycles crash with GPU compute came through 35b1e9fc.
Running Blender in Xcode revealed a few error lines about missing explicit address space qualifiers.

Failed to compile library:
program_source:79651:96: error: pointer type must have explicit address space qualifier
    KernelGlobals kg, ccl_private const ShaderData *sd, const AttributeDescriptor desc, float2 *dx, float2 *dy)

Adding ccl_private in front of every type that was incomplete as in the other shaders was enough to fix the crash.
Please note that I have not tested if the point cloud actually works on M1 (no test scene at hand).

The patch is D13612.
Also #94182 can probably merged into this report.

The render on M1 with cycles crash with GPU compute came through 35b1e9fc. Running Blender in Xcode revealed a few error lines about missing explicit address space qualifiers. ``` Failed to compile library: program_source:79651:96: error: pointer type must have explicit address space qualifier KernelGlobals kg, ccl_private const ShaderData *sd, const AttributeDescriptor desc, float2 *dx, float2 *dy) ``` Adding ccl_private in front of every type that was incomplete as in the other shaders was enough to fix the crash. Please note that I have not tested if the point cloud actually works on M1 (no test scene at hand). The patch is [D13612](https://archive.blender.org/developer/D13612). Also #94182 can probably merged into this report.

blender-admin commented

2021-12-17 14:39:20 +01:00

This issue was referenced by blender/cycles@f60ff20029

This issue was referenced by blender/cycles@f60ff200293478360216692e85019a861559a77f

blender-admin commented

2021-12-17 14:39:20 +01:00

This issue was referenced by 67734d1853

This issue was referenced by 67734d18539743494152428e1c1c105f2ee2fd29

Brecht Van Lommel commented

2021-12-17 14:48:08 +01:00

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

Brecht Van Lommel closed this issue

2021-12-17 14:48:08 +01:00

Brecht Van Lommel self-assigned this 2021-12-17 14:48:08 +01:00

Brecht Van Lommel commented

2021-12-17 14:49:50 +01:00

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

Brecht Van Lommel reopened this issue

2021-12-17 14:49:50 +01:00

Brecht Van Lommel commented

2021-12-17 14:49:50 +01:00

This report predates point cloud rendering so must have a different cause.

Brecht Van Lommel changed title from ~~Blender crashes when using Cycles with Metal GPU in both viewport and renderer~~ to Cycles crash with simultaneous viewport and final render

2021-12-17 14:54:48 +01:00

Brecht Van Lommel changed title from ~~Cycles crash with simultaneous viewport and final render~~ to Cycles Metal crash with simultaneous viewport and final render

2021-12-17 14:55:39 +01:00

Brecht Van Lommel removed their assignment 2021-12-17 14:55:39 +01:00

Michael commented

2021-12-17 15:08:03 +01:00

I forgot to mention the root cause of the crash which I have also seen before the combined M1 + M1 GPU worked.
These crashes happen in intern/cycles/device/metal/kernel.mm:379 'string errors = [err UTF8String];' at the moment:

      for (int i = 0; i < METALRT_FUNC_NUM; i++) {
        const char *function_name = function_names[i];
        desc.name = [@(function_name) copy];

        NSError *error = NULL;
        rt_intersection_funcs[kernel_type][i] = [device->mtlLibrary[kernel_type]
            newFunctionWithDescriptor:desc
                                error:&error];

        if (rt_intersection_funcs[kernel_type][i] == nil) {
          NSString *err = [error localizedDescription];
          string errors = [err UTF8String];

The Metal compiler fails for example when the shader source is incorrent there may be other reasons as well.
Both kernels (device->mtlLibrary[kernel_type]) are therefore nil.
This method call is made on a nil object which is not a bad Objective-C style btw. but a common idiom.

 [device->mtlLibrary[kernel_type] newFunctionWithDescriptor:desc error:&error];

But in this case -[newFunctionWithDescriptor:desc:error] returns nil but *error is also nil.
'[error localizedDescription];' is still ok and returns nil but then [err UTF8String] crashes when err is nil.

That was what I meant, there are different ways to fail a Metal library compilation but so far they all crashed at this line:

    string errors = [err UTF8String];

That could be made more robust.
Also if the environment variable CYCLES_METAL_DUMP_SOURCE is set the source is dumped.
Maybe it is a good idea for the moment to save the metal source string and if this error condition is reached
the metal source is dumped even if CYCLES_METAL_DUMP_SOURCE is not set.

I forgot to mention the root cause of the crash which I have also seen before the combined M1 + M1 GPU worked. These crashes happen in intern/cycles/device/metal/kernel.mm:379 'string errors = [err UTF8String];' at the moment: ``` for (int i = 0; i < METALRT_FUNC_NUM; i++) { const char *function_name = function_names[i]; desc.name = [@(function_name) copy]; NSError *error = NULL; rt_intersection_funcs[kernel_type][i] = [device->mtlLibrary[kernel_type] newFunctionWithDescriptor:desc error:&error]; if (rt_intersection_funcs[kernel_type][i] == nil) { NSString *err = [error localizedDescription]; string errors = [err UTF8String]; ``` The Metal compiler fails for example when the shader source is incorrent there may be other reasons as well. Both kernels (device->mtlLibrary[kernel_type]) are therefore nil. This method call is made on a nil object which is not a bad Objective-C style btw. but a common idiom. ``` [device->mtlLibrary[kernel_type] newFunctionWithDescriptor:desc error:&error]; ``` But in this case -[newFunctionWithDescriptor:desc:error] returns nil but *error is also nil. '[error localizedDescription];' is still ok and returns nil but then [err UTF8String] crashes when err is nil. That was what I meant, there are different ways to fail a Metal library compilation but so far they all crashed at this line: ``` string errors = [err UTF8String]; ``` That could be made more robust. Also if the environment variable CYCLES_METAL_DUMP_SOURCE is set the source is dumped. Maybe it is a good idea for the moment to save the metal source string and if this error condition is reached the metal source is dumped even if CYCLES_METAL_DUMP_SOURCE is not set.

Michael Jones (Apple) commented

2022-01-06 13:04:31 +01:00

As a workaround, this crash can be fixed by setting the environment variable: CYCLES_METAL_DISABLE_BINARY_ARCHIVES="1"

It occurs when additional instances of the same underlying Pipeline State Objects are created in order to do multi-instanced rendering. Pending further investigations as to the root cause...

As a workaround, this crash can be fixed by setting the environment variable: `CYCLES_METAL_DISABLE_BINARY_ARCHIVES="1"` It occurs when additional instances of the same underlying Pipeline State Objects are created in order to do multi-instanced rendering. Pending further investigations as to the root cause...

Jesse Yurkovich commented

2022-01-18 20:26:46 +01:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2022-01-18 20:26:46 +01:00

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

Jesse Yurkovich commented

2022-01-18 20:26:46 +01:00

Will at least confirm this report based on the previous comment.

Brecht Van Lommel commented

2022-01-20 18:42:58 +01:00

Will mark as high priority, since there is a workaround we can do for the 3.1 release.

Brecht Van Lommel commented

2022-01-27 23:38:06 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Brecht Van Lommel closed this issue

2022-01-27 23:38:06 +01:00

Brecht Van Lommel self-assigned this 2022-01-27 23:38:06 +01:00

Carter LaSalle commented

2022-02-25 21:38:42 +01:00

Added subscriber: @Carter-LaSalle

Carter LaSalle commented

2022-02-25 21:38:42 +01:00

I am also having this issue am I am using:
Blender Version: 3.2.0 Alpha, master, 2022-02-20 02:31, 1f79132287
OS: macOS-12.3-arm64-arm-64bit
GPU: Apple M1 Pro Apple 4.1 Metal - 76.3

I am also having this issue am I am using: Blender Version: 3.2.0 Alpha, master, 2022-02-20 02:31, 1f7913228779 OS: macOS-12.3-arm64-arm-64bit GPU: Apple M1 Pro Apple 4.1 Metal - 76.3

Brecht Van Lommel commented

2022-02-28 15:14:29 +01:00

@Carter-LaSalle this bug is supposed to be fixed, if you still encounter it please open a new bug report with example .blend file.

Caden Mitchell commented

2022-02-28 18:58:57 +01:00

Removed subscriber: @Caden-Mitchell

Jacob Wachtl commented

2022-11-28 12:05:12 +01:00

Added subscriber: @jackattack

Jacob Wachtl commented

2022-11-28 12:05:12 +01:00

Im still having the exact same issue. Not only is blender crashing for me- my whole computer crashes. Has this maybe resolved? or is there a different thread i can read about the topic?
When rendering in cycles with metal GPU and having viewport also in cycles everything freezes and crashes...

Blender Version: 3.3.1

I mac 2020, Retina, 27"
Processor: 3.6 GHz 10-Core Intel Core i9
Graphic card: AMD Radeon Pro 5700 8 GB
Ram: 16 GB 2667 MHz DDR4

OS ventura 13.0.1

Workaround at the moment is to not have the viewport in cycles when rendering in cycles

Thank you allready :)

Im still having the exact same issue. Not only is blender crashing for me- my whole computer crashes. Has this maybe resolved? or is there a different thread i can read about the topic? When rendering in cycles with metal GPU and having viewport also in cycles everything freezes and crashes... Blender Version: 3.3.1 I mac 2020, Retina, 27" Processor: 3.6 GHz 10-Core Intel Core i9 Graphic card: AMD Radeon Pro 5700 8 GB Ram: 16 GB 2667 MHz DDR4 OS ventura 13.0.1 Workaround at the moment is to not have the viewport in cycles when rendering in cycles Thank you allready :)

Michael Jones (Apple) commented

2022-11-29 11:42:57 +01:00

@jackattack , thanks for the report. I was unable to reproduce the issue on an M1 Max laptop with 64GB shared memory so I think the root cause may be different. One thing that springs to mind: the Metal backend doesn't handle out-of-memory cases very gracefully yet, so it's possible that doing two renders overflows your GPU's 8GB of VRAM, but one render is okay. Do you know roughly how much memory your scene uses?

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

Cycles Metal crash with simultaneous viewport and final render #94142