Just in case those reports from the last days help to solve this issue.
(If the blender app crashes it’s OK, but not when the computer crashes! I’m kinda scared of if I should press the button and risk to reboot the complete system)
In my opinion it’s related to MacOS GPU (Metal) implementation in blender, from the Apple side. !?
But just a guess.
I got the same issue! I use Mac Pro with MacOS 13, Blender 3.3, 3.4, 3.5 just crash when use cycle rendering. After I downgrade from MacOS 13 to MacOS 12, the Blender 3.3.1lts is ok for cycle render, but the Blender 3.4 and 3.5 have the same issue.
same issue here, i’ve update my macOS version from 12.6.1 to 13.0 last week. the computer system freeze when using cycle metal render with AMD rx6600 blender version 3.4.
so i downgrade macOS back to 12.6.1 use timemachine, everything works fine again!
We’re unable to reproduce the issue so far here with macOS 13.0.1 and AMD W6800X.
Can anyone try removing the .cache/cycles folder in their home directory, and see if that helps? I’m wondering if perhaps cached kernels from older macOS or different Blender versions are interfering.
Hi,
after deleting .cache/cycles blender does not crash immediately. However, it becomes heavily unresponsive (i.e. spinning beachball of death) as soon as I hit F12 to render a scene. The GPU is getting hit with some load, and differently from before the blender windows does not get closed. Just unresponsive.
It took blender around 3 minutes to become responsive again, after which the Blender Render window popped up, showing my image, already the whole 3 minutes as elapsed time, but still a long way to go.
Additionally, my GPU gets only utilized about 50%, so it’s hardly breaking out into a sweat. On Monterey it would get the whole 100% with fans spinning as fast as possible.
Edit: After the first F12 render, I can utilize cycles in the viewport without blender crashing. But as soon as I hit F12 again WHILE using cycles in viewport, the Blender window is gone again with a crash notice from the OS.
Wonderful news: It seems to be a buggy implementation in macOS Ventura.
I have yet to check for myself, but I was just told that with 13.1 beta3 and beta4 the issue with Blender is gone and Cycles can again be used stable.
When my scene gets a bit more complicated, roughly 1,5 million vertex and a couple of lights I get a render error. It renders 1 or 2 frames and then it gives the error.
The memory usage is still rather low.
I run on a Macbook M1 Max with 32GB. (Monterey)
It happens with Blender 3.3, 3.4 and 3.5.
This is the error: CommandBuffer Failed: Cycles_metal_integrator_queued_path_array
Just before it gives an different error, just briefly, so I can not really read.
Hello, I am having a lot of issues with the color wheels and crashes in Blender 3.4 I am on 13.1 but still have crashes within the app and of course when using GPU. Wonder if you found any solutions. Thanks.
Well, there is a hell lot to fix in 3.5, Intel & M1/M2 MaxOS, AMD, Metal, GPU, Cycles and interface issues on Metal.
There is no way to use 3.5 for anything serious than bugreporting.
I filed so many bugreports, I haven’t on any other version since 3.0 +
Not to forget the Mac OperatingSystem crashes with Metal.
That’s the point of this stage of development, big pieces of new development land and with them come bugs, people report them, and they get fixed, this stage is by nature unstable, blender may not even build on any given day.
If you want/need to do work, stick to the official releases or if you really need that stability stick to the LTS releases. If you have the time to spare, play with the latest alpha’s and report bugs on them, but you should not be relying on alpha builds being stable for doing any actual work.
That’s what I do, but what I basically wrote is about that you can’t see the forest because of all the trees.
This is not about that I want to do real work with 3.5.
It’s about that that you run from one bug into the next and when you think you reported all for this day, you’ll find more && you don’t even finished to do all the tests, done usually.
And to have daily builds is good to reach the goals !!
Yes, I’m also having a lot of crashes in 3.4. Trying to render I get these Metal Integrator Errors on animations along with just regular crashes that I wasn’t getting in 3.3.
Optimisation will improve performance - I guess - but in the last 2 years of m1 m2 - it did not change so much. its still much slower than an rtf 3070 laptop gpu - but the battery is dying much faster than the mac book. I fear that apple will change its hardware again, when everything is running smoothly.
I saw this article about the introduction of the Metal backend:
The article promises some significant improvements in render time, however I am still getting the same render times on multiple test scenes as I was getting one year ago. Am I missing something?
In the settings, I set the backend to metal, I restarted Blender. I am using the latest 3.5.0 Alpha on a MacBook Pro M1 Pro with Ventura 13.1.
I just wanted to be clear about what’s being discussed as there may be some confusion.
This thread is for discussing the Cycles Metal Backend.
The article you linked too is talking about the Blender/EEVEE Metal Backend.
Discussions about the Blender/EEVEE Metal backend should probably happen in a different thread.
Enabling the Blender/EEVEE Metal backend should only result in a difference in EEVEE and the general Blender user interface, and not all scenes will see the same performance uplift. Cycles performance should be the same between the OpenGL and Metal backends for Blender/EEVEE.
I am able to reproduce a performance increase with the Metal Backend for EEVEE with basically the same hardware. MacBook M1 Pro (14 core GPU) on MacOS Ventura. Running the Tree Creature demo sees a playback performance increase from ~5fps to ~11fps (Performance numbers will vary between hardware, viewport size, screen resolution, etc).
