I’m a bit puzzled by the M4 GPU results.
Where I get confused is going from the standard M4, the M4 Pro (16 cores) has 1.6x as many GPU cores but achieves 2.2x the performance. Correspondingly the M4 Pro (20 cores) has 2x as many cores (as M4) but clocks in at 2.4x 
Would this come down to the machines tested having more RAM as well as more cores (since in Apple Silicon GPU shares memory with CPU)?
It’s not just about more cores. The more cores also get accesss to the RAM via higher bandwidth. This way Apple can control the performance of the different chips very granular. Nvidia very heavily uses this method to spin up many different product variants from just one piece of silicon.
I think the bandwith can’t be chosen however the engineers like to. With certain core counts, only certain bandwidth ranges are possible, maybe? That would explain the not perfect scaling between some core count variants that you mention. The amount of RAM would only have an impact if that particular test would ask for it (more RAM).
I think you’re on the button there. I see the 20 core M4 has more than double the memory throughput as the 10 core one, similar to the benchmark.
Worth taking note of that specification too when considering purchasing decisions.
there is one small point
of course the m4 with hardware raytracing (M3 and above) is a blender powerhouse but at the moment the version of cycles in Rhino doesn’t support it. I think the cycles version actually implemented in R8 is the first Cycles X (Blende 3.0) version. But I am not sure completely maybe @nathanletwory can tell more about this topic and the future implementation of hardware raytracing support for Cycles on Apple Silicon (M3 and M4 Series)(I think Blender Version 3.6 (with MetalRT and 4.0 and above with real hardware raytracing support for M3 and above)
btw. I also see a huge step forward in the M4 generation and want jump to it in a few days. Hehe I let you know about the feeling of the Jump from my 2016 Intel mac 
Oh I didn’t know that. I got the impression, that the rhino-cycles version is usually not far behind the original blender version. No Apple silicon raytracing support after over a year? This would be quite disappointing. I don’t remember the move to newer cycles versions being mentioned in the release notes. @nathanletwory is there any place where we can get updates regarding the progress of rhino-cycles? I know there are bits and pieces of info from you regarding this, spread throughout various posts here in the forum. Maybe you could make a dedicated thread that just informs about the current status of rhino-cycles like current version, features and when new versions and features are planned for release?
RhinoCycles in Rhino 8 is based on Blender Cycles 3.5.
I am currently working on updating to latest Cycles. Our patches I have already re-applied on top of 4.2.
You can always look at the GitHub - mcneel/RhinoCycles: The Cycles integration plug-in for Rhinoceros 3D for the integration plug-in and GitHub - mcneel/cycles: Fork from Blender Cycles for work on the Cycles codebase. For Rhino 8 there is the branch rhino8_cycles35, for Rhino 9 work is ongoing in the branch rhino9_cycles42. For the integration plug-in the equivalent branches to follow are rhino-8.x and rhino-9.x.
Note that the actual move to the new codebase isn’t done yet, I’m still working on building all the dependencies for rhino9_cycles42. Once that is done the goal is to expose as much functionality in Rhino 9 as possible. I imagine that there will be posts in Rendering WIP whenever there is something useful to test or when I need feedback from users.
Thanks, the github pages are ok to get info about the rhino-cycles, though it isn’t very simple and straight forward for people who aren’t software developers.
So you mean you test the newer cycles version (42) in rhino 9 wip first and after that works well you then bring it to rhino 8?
There will be no Cycles version update in Rhino 8.
I just want to report - I got my M4 max (16-40 with 64GB) end of last week and it is blazing fast!
I did a rendering of the Rhino bus with 3000x2000 pixels and 500 samples in Cycles - it was done in 29 seconds.
I also try the Blender classroom scene and this was done in just 14,5 seconds (standard scene settings rendered with GPU)
But I got some problems with the bus and the viewport speed (testmaxspeed). With the settings from the McNeel website I just get round about 34 fps or it freezes round about 50% of the test (I don’t send the report).
The overall work speed with Rhino is amazing and it is very fast in Rendering and also with raytraced Viewports.
Let me know if I should test anything else.
It’d be more useful if you did send in the report.
maybe we have to split it here . . .
I am able to replicate the freeze with the bus 3dm. But actually I cannot sent the error report because I have to force quit the app and there is no crash dialogue (like normal).
I get the freeze while the exact 4th run of the testmaxspeed command it is getting slower run per run 35 fps, 29 fps , 21 fps - crash.
I am also able to freeze rhino with rotate the view in under render mode after 20 seconds of turning. Until know I get this freeze just with the bus file. I also tried to save it as Rhino 8 first. Other files are a lot faster with test max spee command → 100fps and more.
A few years ago I bought Maxwell Render 4, using it with Rhino 5 (Mac).
NextLimit are still bombarding me with specials to get me to upgrade to MwR 5. It would be nice having plugin compatibility (I’m now on Rhino 8) but seriously, after all this time MwR still only supports CUDA GPUs and isn’t even Apple silicon native.
Would hardly call it an upgrade.
even if you were on windows, don’t buy the upgrade. It’s been nothing but disappointing, not working properly with Rhino 8, nor the 4000 RTX series.
You could give ‘bella render’ a try if you haven’t already, and you are looking for a replacement.
It is CPU only for the time being, except some minor GPU processes; but it’s fast and with Mac implementation and great Rhino integration.
Thanks for the heads-up. I’ve always found MwR unstable and unfriendly (but produced good results and I liked the way it did materials). So where you might be disappointed, I might not be – my expectations are pretty low to start with. 
I also found a scenario where the rendering was incorrect (the path of a beam of light through a prism).
I have had it installed for a couple of months. Found it to be fast, but quite unstable, crashing Rhino frequently. I’m only a hobbyist though, so can afford inconveniences.
fwiw I currently know of one crashing case, apparently only on mac (and seemingly more prevalent on intel or under rosetta), but I have not yet isolated it; in the meantime, something that may help is to go in preferences > advanced, search “bella”, and disable material previews (and realtime sliders, depending your preference), just to reduce the likelihood, and also to keep things snappier & not bogged down rendering lots of thumbnails
oh, you’re right, it always has been unstable and great in rendering at the same time. since I first used it back in 2007. I know what you’re talking about. Also I always liked the way of material handling as well (once finally understood ). however, with the new versions the dispersion still doesn’t work with GPU. And dispersion was the only reason to use it , at least for me. Although I haven’t tested it with the 14900K cores, I’d prefer rendering with GPU.
It’s not that I’m disappointed, I simply can’t afford to use the entire capacity of my workstation for days to render a sequence.
