Wouldn’t it make more sense to assume that it has to do with Intel driver bugs fixed in Ventura?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
3D Rendering on Apple Silicon, CPU&GPU
- Thread starter vel0city
- Start date
- Sort by reaction score
Wouldn’t it make more sense to assume that it has to do with Intel driver bugs fixed in Ventura?
What makes you think it has anything to do with Metal 3 then? There is nothing in the patch that makes any reference to Metal 3 APIs.
yes there is for Krita
GitHub - sddebz/stable-diffusion-krita-plugin
Contribute to sddebz/stable-diffusion-krita-plugin development by creating an account on GitHub.
github.com
Was neat to see Octane X and Da Vinci running on the new M2 iPads. (Surely that will quieten the people complaining about lack of pro apps right on iPad right?)
Kind of cool you can now go Nomad Sculpt > Procreate > Octane all on the iPad. The only thing that is missing is decent uv tools.
Does anyone use octane on AS? Wondering whether the performance is actually any good - was slow on my m1 mba, but with 30% uplift in m2 GPU might be good for lookdev / surfacing (plus the rendr network for final frames could be pretty compelling).
Kind of cool you can now go Nomad Sculpt > Procreate > Octane all on the iPad. The only thing that is missing is decent uv tools.
Does anyone use octane on AS? Wondering whether the performance is actually any good - was slow on my m1 mba, but with 30% uplift in m2 GPU might be good for lookdev / surfacing (plus the rendr network for final frames could be pretty compelling).
lol no. It's not like the arrival of any previous ones did. Honestly I think it's mainly a dev environment that will since (anecdotally anyway) most complaints seem to be mainly from coders.
Part of the problem is that developers are limiting the apps on the iPad. The iPad version of Keynote (for example) is not as full featured as the Mac version. (I don't use 3D tools so I don't know how full featured they are)
It's not really developers who are limiting the iPad, it's Apple themselves, because they require everything to go through App Store review where they can enforce a bunch of silly rules.
This means that Blender for example can't just release a version for the iPad because a) they'd have to have an almost full-time employee uploading builds to the App Store and dealing with review issues - despite the App being free. And b) Apple wouldn't let Blender through review without a couple of years worth of changes to tailor the entire app for the iPad with its touch based UI and file system.
Then there is Apple's rule about apps not running executable code which probably means that Blender's entire python script support would have to be ripped out.
This means that Blender for example can't just release a version for the iPad because a) they'd have to have an almost full-time employee uploading builds to the App Store and dealing with review issues - despite the App being free. And b) Apple wouldn't let Blender through review without a couple of years worth of changes to tailor the entire app for the iPad with its touch based UI and file system.
Then there is Apple's rule about apps not running executable code which probably means that Blender's entire python script support would have to be ripped out.
It looks like Apple is going to start optimizing Cycles very soon. Full Metal Blender is getting closer and closer.
developer.blender.org
Why do optimizations require macOS 13? Because of Metal 3?
Cycles Apple Silicon optimisations
**Tasks** For tracking Apple Silicon specific optimisations (macOS 13.0+). - [x] Architecture specific parameter tuning - [x] Threads / Threadgroup - [x] Num concurrent states / busy states - [x] Work scheduling improvements - [ ] Add new multi-device abstraction for sharing WorkTileSchedul...
developer.blender.org
It looks like Apple is going to start optimizing Cycles very soon. Full Metal Blender is getting closer and closer.
Why do optimizations require macOS 13? Because of Metal 3?Cycles Apple Silicon optimisations
**Tasks** For tracking Apple Silicon specific optimisations (macOS 13.0+). - [x] Architecture specific parameter tuning - [x] Threads / Threadgroup - [x] Num concurrent states / busy states - [x] Work scheduling improvements - [ ] Add new multi-device abstraction for sharing WorkTileSchedul...
Gotta get Full Metal Blender prepped for the forthcoming ASi Mac Pro debut...! ;^p
It seems like they fixed a lot of driver bugs in Ventura. No idea why they can’t back-port those fixes to the previous version.
I’m completely hypothesizing here…. but I suspect it’s not a technical reason and more a business reason.
Apple has demonstrably always been ok to drop support for legacy technologies (floppy disk, dvd drive, headphone jack etc….). I think the same also applies to their software strategy where it is used as a carrot to get folks to upgrade from one version of the OS to the latest where apple can control development investment spend. I think that is largely the consideration here.
It is one of the advantages of Mac OS …. it forces third parties to keep their apps up to date to leverage latest/greatest Apple framework technologies. On the negative side , it is also a disadvantage …it forces third parties to keep their apps up to date… not all vendors do!
Just my 0.02
The way I understood is not that is uses a metal 3 feature but rather a fix how some things are calculated.It looks like Apple is going to start optimizing Cycles very soon. Full Metal Blender is getting closer and closer.
Why do optimizations require macOS 13? Because of Metal 3?Cycles Apple Silicon optimisations
**Tasks** For tracking Apple Silicon specific optimisations (macOS 13.0+). - [x] Architecture specific parameter tuning - [x] Threads / Threadgroup - [x] Num concurrent states / busy states - [x] Work scheduling improvements - [ ] Add new multi-device abstraction for sharing WorkTileSchedul...
Here is what they said on another Metal Patch:
This patch enables MNEE on macOS >= 13. There was an inefficiency in the calculation of spill requirements, fixed as of macOS 13. This patch also adds a temporary inlining workaround for a Metal compiler bug which causes mnee_compute_constraint_derivatives to behave incorrectly.
Could the fix it in Monterey who knows.
Last edited:
I agree that the App Store does impose restrictions that limit the release of many apps but even when the restrictions aren't the problem developers don't bother to add features (in my example, Keynote, the app doesn't have the same animation build order capabilities on iPad as it does on macOS).
Why are Metal optimizations tied to the latest version of macOS? If they weren't, Apple could bring Metal optimizations faster and to more versions of the operating system, not just the latest one.
Because that’s how Apple does things. Their OS releases are tightly coupled software bundles. This strategy has a lot of drawbacks, but also some advantages.
IIRC Apple has always done this. It was something of a difference between how MS does (some) API updates versus how Apple did them.
They’re probably just prioritizing the latest OS because they want blender to be in the best shape for Ventura’s release. Once everything is good there, then back port (which could potentially be done by other blender devs).
Two years since the thread started, over 1000 posts, and people here are still waiting for optimization and support. I’m wondering how users work and what tools they use to get an income.
Two years ago there were no Octane, Blender Cycles, Redshift, etc… so a lot has changed.
Obviously you can only optimize raytracing so much without an actual hardware raytracer, it can still get a bit faster, but it won't compete with a Nvidia card with the right hardware.
Obviously you can only optimize raytracing so much without an actual hardware raytracer, it can still get a bit faster, but it won't compete with a Nvidia card with the right hardware.
It looks like actually they are using Metal 3 features, just the "boring" ones related to offline shader compilation and shader binary archives.
I have no idea how much shader switching is being done, but if they were previously having to compile shaders at run time for different materials while rendering then this could be a nice little speed-up.
Yeah, the shaders used in Blender seem to be massive. Especially when you take shader specialisation into account, which radically increases the amount of code variants that have to be compiled.