macOS: Support arm64 #78710
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
59 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#78710
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Remaining tasks:
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscribers: @JulianEisel, @sebbas
Added subscriber: @Stefan_Werner
Added subscriber: @blenderrocket
Added subscriber: @JacobMerrill-1
Added subscriber: @Gilberto.R
Will blender work in Ipad? :O
No. They do not have the required graphics capabilities.
The next generation of Apple devices will all be using arm64, not just the iPhone/iPad ones.
Added subscriber: @2046411367
Added subscriber: @juang3d
This comment was removed by @juang3d
Claiming this one for now.
This issue was referenced by
9715ad5acaAdded subscriber: @Alaska
Added subscriber: @Sigra
Added subscriber: @christian-clavet
Just a question out of curiosity about this. Will the port work without Blender using METAL from GL on the new Apple devices? (I mean, blender using Vulkan/MoltenVK)
I was thinking they dropped OpenGL, OpenCL for Metal...
Added subscriber: @MetinSeven-1
Added subscriber: @atomicguy
Added subscriber: @pentagramwookie
Added subscriber: @Jimmy-Watelle
Added subscriber: @mehmetoguzderin
Added subscriber: @FrancoisRoussel-3
Added subscriber: @hjarrell
Added subscriber: @Ali6
Excited! Can't wait to have Blender running natively on my ARM MacBook! Also would be cool to update the Blender app icon on MacOS to be consistent with all MacOS Big Sur app icons.
will this also make running blender on Jetson Xavier easier as well?
Added subscriber: @shaunsingh0207
OpenGL is still supported iirc, just deprecated. OpenCL is also deprecated but available while targeting the GPU, and is not supported when targeting the cpu. It would still be a good idea to start using METAL/MoltenVK nevertheless
Added subscriber: @hargettp
Added subscriber: @orange_wedge
Is there any useful news?
By the way thanks for actively working on this; the M1 is a pretty surprising chip and I can't imagine what Blender could do, with a native support.
Happy new year!
You can find a highly unstable version here: https://github.com/skwerner/blender/releases/tag/v2.91.0-mac-arm
for me it renders like 1/5 times, but when it does it is very fast. Seems like only Eevee and CPU cycles work though, and openimagedenoise doesn't work yet
Right now this is a one-person job by Skwerner, and he seems to have a full-time job as well, so progress is understandably slow. Rosetta version is working well for me though
Added subscriber: @gintszilbalodis
Thanks.
I want to learn Blender, but I'm not in a specific hurry, therefore I'll wait for a native apple silicon version and start with a blank slate.
Added subscriber: @howardt
There may be an issue making the Boolean Exact mode work on arm64. It needs a bump of the GMP library to 6.2.1, but the website for that says: "While we added support for Apple's new Arm based computers, our support has a problem. The problem is that Apple reserves CPU register x18, but GMP's mpn/arm64 assembly code uses that register. While GMP runs fine in our tests, we expect things to go awry in some execution situation. (Apple has not been kind enough to specify how they use x18. Therefore, we don't know what the consequences of using x18 might be.)"
This issue was referenced by
886486615bAdded subscriber: @brecht
Standard wiki build instructions for building Blender on macOS can now be used on Macs with ARM processors, using the precompiled libraries.
Note that we have all libraries except for Embree and OpenImageDenoise, so Cycles does not yet have full performance and features in this build. An x86-64 build is likely to still render faster than arm64 until Embree is added.
For the remainder of the work, I will do the Cycles specific changes, the rest is being handled / coordinated by @sebbas.
Added subscriber: @ponderz
@ponderz Just added you to the discussion. The goal for us will be to finish all the infrastructure tasks before the 2.93 release.
@howardt, booleans seem to be working fine in a simple test here. I guess we'll hope there is no problem, and if an arm64 specific boolean bug pops up we know what to suspect.
@brecht Did you hand test a boolean with Exact solver picked? I think the current regression tests for Boolean and Modifiers only check the Fast mode (though I could be wrong). In any case, good news if it works as is. If you didn't update the library, I the library is properly adapting to using portable C code only rather than SIMD instructions.
Removed subscriber: @MetinSeven-1
Ah, I did not test 6.2.1, just the existing 2.6.0. I did a manual test with the exact solver, and ran the automated tests.
I guess we are not in a rush to update to 6.2.1, and by the time we do update it will hopefully will have had more testing. It would be good if there was an automated test for the exact solver.
Added subscriber: @Memento
Added subscriber: @DougRichardson
Added subscriber: @flogic
Removed subscriber: @flogic
Added subscriber: @SarunasAtkocaitis
This issue was referenced by None@62566
Added subscriber: @tudortchirila
I had asked before - will this help with SOC like Quartz64 or nvidia jetson Xavier also? as they are also arm64?
Yes, it also helps for those. However setting up a Linux arm64 build with all these optimizations is not as easy as a macOS arm64 build, since we do not provide precompiled libraries for that.
Added subscriber: @aomizu
This issue was referenced by
af940c68cbThis issue was referenced by None@62575
Added subscriber: @bireos
Added subscriber: @chr.schmitz
Added subscriber: @satrioyamanda
Added subscriber: @Ademuk
Added subscriber: @pannous
Added subscriber: @Joc1
Added subscriber: @huhund
Added subscriber: @MHEonM1
Added subscriber: @Miro-Virta
FYI, filed this task today...seems to be a crash in OSL calling LLVM on Apple M1: #86530
When trying to load LuxCoreRender on the m1 native build, it results in a python error. LuxCore works fine on the rosetta build, and is the only photorealistic gpu render thats available for the m1 atm
First report the error to the LuxCoreRender developers, if they think it's a bug in Blender they can report it with more information.
Note that you would need a LuxCore plug-in compiled for Arm, you can't mix a Blender Arm build with a plug-in compiled for x86-64, the architectures must match.
Thank you! I was using the plugin meant for blender x86 so I assume thats the problem, I have a few other plugins that worked well under arm blender so that was why I was wondering
Ill contact them about the issue
Added subscriber: @evgenijkostrika
Just wanted to say thank you for supporting of Apple Silicon! Can't wait to use the official release! I use 2.92 via Rosetta so far.
Added subscriber: @corbindunn
Added subscriber: @Hello9999901
Added subscriber: @pb29
Added subscriber: @sachcat
Please, would love to see the performance on this SOC
Added subscriber: @kevinzhow
Added subscriber: @jkkiwi
Added subscriber: @andreyrd
Added subscriber: @Pikoo
Added subscriber: @CookItOff
Added subscriber: @MarcoHoo-3
There is now a macOS arm64 build on:
https://builder.blender.org/download/
We're still waiting for the new buildbot infrastructure to build this automatically, for now we have a manual build here that will be updated less often. Please give it a test and report any bugs you find to the tracker.
Hi! I’m pretty new to Blender, and even newer to the Blender community. I’ve only been using Blender for around a year or so. I have noticed a few nuances, just from the first few times of using it. Here are my specs:
First, I would like to thank everyone who has worked on this. The startup time for Blender is so much faster, and it is GREAT. Also, Eevee rendering is around 2.5 times faster for me (92-ish down to 38 seconds).
This is not-really-a-bug, just something I noticed:
I also have a question that I am hoping someone can answer:
Once again, THANK YOU SO MUCH, and I wish you a good day!
test.blend
Hi! Firstly, EEVEE rendering is run on the GPU, while Cycles rendering is run on the CPU. Since EEVEE rendering is run on the gpu, the code was already largely native, which means EEVEE isn't going to see many performance improvements in the native build.
Since Cycles rendering is run on the cpu instead, you should see sizable performance improvements, for me that was about 30% but it may vary based on your scene
Lastly, for cycles selecting gpu compute will still use CPU, gpu is not yet supported on the m1 chip and won't be until either metal or moltenVK is implemented. I'm not exactly sure why it shows that, but its just a visual bug.
A basic run-through feels much snappier than before; thanks to all Blender contributors for taking it so far! 🙌
Removed subscriber: @tudortchirila
This comment was removed by @Hello9999901
Hi, shaunsingh0207!
After your message, I downloaded both the 2.93.0 for Apple silicon and Intel x86. It turns out that it was something iffy with 2.92.0 that made EEVEE really slow. You are right; EEVEE did not see much change, while cycles did speed up, for me 40-50 percent. Thank you so much for your reply!
(sorry for the deleted message, had some errors)
— Hello9999901
Hello.
For now it seems to be working really fine. The rendering times are better with the native ARM version, especially the open image denoiser which is many times faster compared to the rosetta emulation.
I'm totally amazed by the performance of the M1 equipped machines, they seem to handle everything so easily without even getting warm. The difference with intel machines is abysmal.
Many thanks to the Blender dev team for embracing this new technology so fast.
Removed subscriber: @Gilberto.R
Added subscriber: @Zandman
Is it true that the Intel denoiser is still unavailable? The node says "Disabled, CPU with SSE4.1 is required."
The intel denser is working for me,
, the task also looks like its completed
Yes, that's what I thought too. But on my Macbook Air M1 it is disabled. I've attached a screenshot of the node (new project, in compositor add Denoise node). And my SystemInfo.txt.
system-info.txt
Same thing here. Denoising working like a charm for rendering but unavailable as a compositing node.
This issue was referenced by
c75b2019e1The node actually works, it's just the message that should not be there. I'll fix that.
I see this is all committed to master branch. However, I'm unable to build it myself on my M1 system. I'm simply following the "Building Blender for macOS" instructions. Am I missing something?
I don't have a
M1Mac, so I'm sorry if this doesn't work. However one of the errors I'm seeing from your build log isMac OSX requires pre-compiled libs at:This suggests you don't have the libraries. From my understanding to get the libraries you just need to runmake updatein the terminal in the Blender source directory, wait a while for everything to download, then build Blender withmake.It's also possible that GIT/SVN isn't picking up that you're on a
M1Mac and thus isn't downloading it. In which case that will need to be fixed by the dependency maintainers. But in the meantime this may help?/Users/YOUR_NAME/Blender-git/lib/svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin_arm64//Users/YOUR_NAME/Blender-git/blender/and run then run themake updateandmakecommands./Users/YOUR_NAME/Blender-git/build_darwin/or/Users/YOUR_NAME/Blender-git/build_darwin_arm64/then building again withmake.CMakeCache.txtfile (or a file like it) in/Users/YOUR_NAME/Blender-git/build_darwin/and change all the paths that point to../lib/darwin/to../lib/darwin_arm64/Once again, I don't have a
M1Mac, and so may be wrong in this. But I'm hopeful this may help.Thanks! The manual SVN checkout of the darwin_arm64 repo worked and I now have a working build!
Removed subscriber: @aomizu
Added subscriber: @DefaultCubeVFX
Added subscriber: @flogic
Added subscriber: @Neptun3
i import a .obj and it crashes when i go into sculpting mode and try to smooth the mesh
This issue was referenced by
db021ee2eaHaven't nailed this down to when it would have failed, and happy to file a new ticket, but can't build on Apple Silicon anymore. Getting:
I even trashed my
lib/directory, so that I could refetch all dependencies. Did that, plus this and still getting the error:Just actually upgraded to macOS 11.3, in case that could have done it. Even after updating Xcode still getting it.
@hargettp I struggled a few days with the same error message. It worked for me again after I trashed the complete build directory -- in my case 'blender_darwin_full'.
I compile with:
I got a different error after updating Xcode. Can't quite remember, but it was something like
"unable to find sdk 'macosx11.1'". I did amake updatefrom the Blende repo. That didn't help. I then tried to recreate the Xcode project by doingcmake . -B ../build_xcode/ -G "Xcode", but that also threw an error. After some Googling I found that I needed to re-install the Xcode Command Line Tools. But that also didn't help. Finally, I created the first symlink from this article and I was able to build again: https://developer.apple.com/forums/thread/667561ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdkCan't reproduce, I'm also on 11.3 Apple Silicon.
Yeah, false alarm. Apologies.
Added subscriber: @Lucas-Bleackley-Petter
It seems like Screen Space Reflections doesn't work in Eevee on Apple Silicon, but it works on Intel. Anyone else experiencing this? The issue is happening on a Mac mini M1, on both 2.92.0 and the latest 2.93.0 Beta (
c75b2019e1) with clean installs of Blender.Here's an example .blend file with an emissive cube on a black plane, and SSR enabled.
Screen Space Reflection Test.blend
Opening that file on a 2018 MacBook Pro (Intel) running 2.92.0 on macOS 10.15.7, reflections show in the viewport and render as expected:
But on the Mac mini M1, running either 2.93.0 Beta or 2.92.0 on macOS 11.3.1, it won't create reflections in the viewport or in renders; however a very thin, subtle glow beneath the cube is visible:
Just help to help better see the thin glow in the image above, here's the same render from the Mac mini, but with SSR disabled:
I did some searching, and this post on StackExchange seems very relevant but the user didn't upload a .blend file to confirm. Also, #87801 (Eevee ambient occlusion is incorrect on M1 macMini) looks similar to this, but it's regarding Ambient Occlusion.
Thanks for supporting the Mac arm64 platform!
Hi! I confirm there is a problem with screen space reflections in eevee. It's working but not rendered properly.
If you adjust the roughness setting of the material, you can see that the reflection is there but not rendered as intended.
Removed subscriber: @christian-clavet
Added subscriber: @cerlyu
Please report any bugs to their own reports, it's easier to keep track that way and ensure it gets looked at by the right developer.
Thanks, Brecht. The issue is now in reported in #88241.
Can we please get a new alpha build? Blender keeps crashing, not sure if a new M1 build would fix this.
Added subscriber: @lowpolysaac
Thanks devs for working on this!
Today I decided to completely delete the Blender repository and related stuff (the
Blender-gitfolder) and do a fresh checkout and build of the source code. To my surprise I again stumbled upon the fact that the build failed, because thedarwin_arm64libraries weren't downloaded. I decided to look into the matter and it turned out that my system somehow has both an Intel and an ARM version of Python3 installed. And the Blendermake updatetarget used the Intel version. So the call toplatform.machine()returnedx86_64, which caused the wrong libs to get downloaded.Now, I have no idea how I got into this mess. I guess I have some Python sanitizing to do... I know this isn't really a Blender issue, but I just wanted to follow up for those interested.
Removed subscriber: @Ali6
I see the other versions of Blender have had the fix for the viewport or timeline jumping large distances when "trucking" (cinematography term) the mouse off the screen, for quite a while now; so I'm not going to file a bug report knowing it's been addressed.
I would just like to add to the voices to update the master build when possible so this fix can be part of the ARM64 build. This is a super annoying glitch.
Thanks!
There's a newer build here:
https://builder-prod.blender.org/download/daily/
This updated buildbot is planned to be replace the existing one in the next few days.
This issue was referenced by
b158477551Where has this been fixed? I'm noticing a similar issue when dragging nodes in the Node Editor (i.e. Compositor tab). Very irritating. Seen it happen on that official latest M1 build that was released yesterday and also on my own bleeding edge builds from the latest master. So either this is a new bug or that old one hasn't been fixed.
Added subscriber: @ardah
Added subscriber: @hkstrydrx
Changed status from 'Confirmed' to: 'Resolved'