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 !!
Anyways, have a nice Christmas! 
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.
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).
The Tree Creature demo can be downloaded here: Demo Files — blender.org
Hello,
I’m trying metal rendering on the M1 Max and M2 Max (30 core) in Blender Alpha 3.5, with the BMW scene.
M1 Max (GPU): 42 sec
M1 Max (GPU) + M1 Max: 50 sec
M2 Max (GPU): 21 sec
M2 Max (GPU) + M2 Max: 36 sec
It seems when using both gpu and cpu it becomes slower, is it an expected behaviour?
In my experience, the GPU ends up waiting for CPU buckets to finish, so I would say this is normal on a realtively quick render.
Thanks for the reply. So it should be assigning different tiles to cpu and gpu and render them simultaneously?
I tried the Classroom scene as well, but I still get (much) slower render when enabling both GPU and CPU.
I’ve set the tile size to 256 but I only see one tile rendering at a time.
M2 Max (GPU): 52 sec
M2 Max (GPU) + M2 Max: 1 minute 52 sec
Unsure on the details for this implementation - I just pop onto this forum as its a good place to see what the current state of MacOS rendering progress is. My point is that the GPU is so much faster than CPU and my experience with Redshift with mixed rendering (both CPU and GPU, and even different GPUs) is that in certain situations there’s no advantage to mixing. I’m keeping an eye on how the Cycles/Apple tech is coming along.
Hi, no idea about the performance issue with GPU+CPU but tiling is only to save memory, it is always slower.
Cheers, mib
I don’t know if it’s realistic, but it would be a tremendous win for Macs if we could have the CPU and GPU cores pull their full weights with little overhead. Especially in the high end configurations, it feels like we’re leaving a lot on the table because it’s either/or.
Seeing that a new Mac Pro is just around the corner and the GPU grunt of Apple Silicon is a bit lacking, it would really be great if, in AS Macs, we could consider the CPU+GPU as a two punch blow.
The so called “give me all you’ve got” mode, just keeping two or so efficiency cores reserved for system tasks to prevent any lockups.
Maybe this gives you an answer!
This is about HIP, but tells you what else they are up to with cycles development in the near future…
Am i doing something wrong, with defaut scene cycles keeps hanging up. I change system settings, “Cycle Render Devices” to metal/gpu and then cycles to gpu. On base m1, blender 3.5b, same with 3.6a
After installing v3.5 Blender began hanging when working with materials. The app would just freeze, especially when creating a more complex series of textures connected with vector and math for setting normals, roughness, and color ramp inputs. Eventually I solved the problem by switching Preferences > System > GPU Backend from “Metal” to “OpenGL”. I haven tested to see if the problem occurs if using Metalwhen rendering with Cycles.
I believe this issue has been fixed in Blender 3.6 and is expected to be back ported and released as Blender 3.5.1 some time soon.
Please try Blender 3.6 and see if it helps. Blender Builds - blender.org
This would be down to the tile dispatcher to utilise each type of core more efficiently. To do this it needs to know the relative performance i.e. it may be better to hold off dispatching the final tiles to CPU cores as the job would be completed quicker by waiting for the next available GPU cores.
But this isn’t the real benefit of mixed/unified architecture. That would be to deconstruct the render pipeline to determine the performance of different cores on each stage as even a CPU efficiency core may execute some stages faster than a GPU core. A stage dispatcher could then allocate stage-appropriate hardware with maybe a pool of rays to pick up under utilised cores.
I have tested just between yesterday and today in my Hackintosh. Mayor regression going from Monterey to Ventura.
Intel i9 10940X - 64GB RAM - 2xAMD Radeon 6950XT
Scene White Lands Demo file.
Monterey 12.6.5 and Blender 3.4.1 - Artic Ocean - 40.24 seconds
Monterey 12.6.5 and Blender 3.5.1 - Artic Ocean - 38.87 seconds
Ventura 13.3.1 and Blender 3.4.1 - Artic Ocean - 54.40 seconds
Ventura 13.3.1 and Blender 3.5.1 - Artic Ocean - 57.63 seconds - Metal Viewport
Ventura 13.3.1 and Blender 3.5.1 - Artic Ocean - 59 seconds - OpenGL Viewport
Scene Scanlands crashes at 100% no matter what settings in viewport (Metal or OpenGL) also 3.4.1 and 3.5.1
This is my first post so maybe this is not the right place to write this message.
I had no idea how well the Metal backend was going until while cleaning up some mocap I accidentally hit play while I had Eevee enabled on my M1 mini, which is the base of all Apple Silicon machines. Only time it dipped below 30 was because of the screen recording. Animating with Eevee enabled was never an option for me pre re-write, not even close. Feedback would be that y’all are doing a great job!
Context: Working on a 4K screen (default scaling) Rig had at least 100 joint correction morphs driven by the rig. All textures are 4K. Still can’t have particle hair enabled though. 
Used Quicktime to screen recorder which is a hog for comparatively.
Just wanted to share my surprise and thanks. 
Just for reference, it seems you’re talking about the benefits the Metal backend for EEVEE is offering you, not the Metal Backend for Cycles that this thread is about.
Oh, looking at the title I see you’re correct. My brain must have straight skipped over that. Sorry about that! Please feel free to move it to the Eevee thread.
Thanks.