Thank you, Apple, Michael, Brecht, and the team for making Metal happen!
I installed the Apple Silicon build 3f96555123db on a 2020 Mac Mini M1, and so far can’t get the GPU to work. In Preferences, under System, it shows a Metal option. But when selected, it then says “No compatible GPUs found for Cycles.” And in the Render settings, when the Device is set to GPU Compute, the option becomes greyed out.
The 2020 Mac Mini M1 has an 8-core GPU, so I’m not sure what’s going on. Will this machine be supported? Looking forward to trying out Metal.
Lucas, in Brechts initial notification it is mentioned that macOS Montery (12.0.1) is required for now, are you on Monterey yet, or still on BigSur…?
I’ve tried my own builds with the published patches leading up to this. They have rendered out great—even complex scenes—but they have crashed as soon as I have Cycles as renderer and enter rendered mode in the Viewport. I didn’t want to report it until the build from you guys was official (since it could be something on my end), but I still get the same crashes with today’s alpha:
Do you have both check boxes ticked under the Metal options in preferences? If I have just the “GPU” option checked everything works great. If both are checked (I’m assuming the other is for CPU) then I’m crashing in viewport.
@brecht should we file bug reports, like crash reports, here or through the normal channels of the bug tracker? Or should we use this thread only for initial thoughts and desires?
Thanks for all the hard work! Performance is great, about 3-4x faster rendering than CPU. I do get a lot of crashes though in the rendered viewport with any apple silicon build, with the GPU they seem to be even more frequent than with the CPU (âš“ T93199 Crash when playing animation in rendered view (cycles)).
I hope so! With both boxes ticked for F12 render it’s faster. As of right now if both boxes are ticked during viewport renders this causes the crash.
I hope both are functioning properly in the future so as to add performance to viewport renders.
Just wanted to verify the speed as well. A test scene here renders 2m26s with both boxes checked and it took 4m0s with “just” the GPU box checked.
I hope @brecht and gang can condition the code so that we can have both boxes checked and let the Viewport just use GPU, or better yet: fix the issue so that both can be used in the Viewport too.
Hi! Thank you so much for supporting metal with blender.
The first tests are really impressive. On my M1 MacBook air here are some results for a scene :
Hey, I just tried out the new alpha on my M1 MacBook Air and here are my results:
Blender 2.93 CPU 25 Samples:
46.14 seconds
Blender 3.1 CPU 10 Samples:
48.93 seconds
Blender 3.1 GPU+CPU 10 Samples:
34.42 seconds
Blender 3.1 GPU+CPU 25 Samples:
50.80 seconds
Still hasn’t quite hit previous performance, but for the first iteration it’s pretty great, only needs to improve by 10 seconds to be better than what I used to get.
NOTE: would have compared to 3.0, but the times are not great. The single render region, and denoise after rendering changes have destroyed my CPU render times.
That’s really odd, I have not seen any scene where the tiling and denoising changes could explain such a performance difference. That’s something that could be reported to the bug tracker, if it’s really the same scene and rendering settings in 2.93 and 3.0/3.1.
It’s not only on m1 that the performance is horrible, I’ve checked in several places, and it seems to be rendering with any CPU is absolutely horrible compared to before…
Some are only effected a little, like the M1; but I saw one person have their performance cut in at least a fifth by the 3.0 update.
Looks like the 3.0 update only improved how GPUs are used, while kind of forgetting about CPU users…XD
We haven’t seen anything like that in our testing and no bug reports with that kind of performance difference. So if there is such a scene we are interested in getting a bug report so we can investigate.
