macOS: Support arm64 #78710

Remaining tasks:

D8236: macOS: changes to build library dependencies for arm64 - also contains patches for dependencies that may have to be submitted upstream.
D8237: Cycles: support neon instructions for arm64 processors
Use Embree (see discussion in D8236)
Use OpenImageDenoise (upgrade to 1.3.0, see #85365)
Fix failing tests
- Cycles hair tests (due to not using Embree, blacklist or use Embree)
- Cycles world volume test
- ffmpeg (http://trac.ffmpeg.org/ticket/9060)
- physics_ocean
Add precompiled libraries
Update macsOS release package names to include architecture
Add buildbot worker
Update buildbot download page
Update blender.org download and system requirements page
Fix warning on startup about unknown GPU name

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 9715ad5aca

Added 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

In #78710#1054065, @christian-clavet wrote:
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...

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

In #78710#1088720, @shaunsingh0207 wrote:
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

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 886486615b

Added 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 af940c68cb

This 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

In #78710#1128876, @shaunsingh0207 wrote:
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:

MacBook Pro 13 M1 (1TB SSD, 16GB RAM)

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:

The rendering times are almost exactly the same for Blender 2.92.0 running through Rosetta 2. On a test scene, (file below), I got roughly 56-58 seconds on the Alpha version and the stable 2.92.0 version. I am not sure whether it is because the ARM processes still have to optimized.

I also have a question that I am hoping someone can answer:

Does GPU compute use the 8-core GPU on the M1 SoC (for M1 Air it can be 7-cores, but for high-end Air and Pro it is 8-cores), or does it still use the CPU for rendering? I’ve been getting roughly the same times with GPU compute and CPU. (This is Cycles)

Once again, THANK YOU SO MUCH, and I wish you a good day!

Hello9999901

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

Specs:
- MacBook Pro M1 2020

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

In #78710#1148306, @shaunsingh0207 wrote:
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 c75b2019e1

The 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?

leon@Leons-MacBook-Air blender % make

Configuring Blender in "/Users/leon/Blender-git/build_darwin" ...
-- The C compiler identification is AppleClang 12.0.0.12000032
-- The CXX compiler identification is AppleClang 12.0.0.12000032
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detected native architecture arm64.
objc[4348]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x2008cc188) and ?? (0x116ddc2b8). One of the two will be used. Which one is undefined.
objc[4348]: Class AMSupportURLSession is implemented in both ?? (0x2008cc1d8) and ?? (0x116ddc308). One of the two will be used. Which one is undefined.
-- Detected OS X 11.1 and Xcode 12.4 at /Applications/Xcode.app/Contents/Developer
-- SDKs Directory: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
-- Detected OSX_SYSROOT: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk
-- Found Git: /opt/homebrew/bin/git (found version "2.31.1") 
-- Performing Test SUPPORT_NEON_BUILD
-- Performing Test SUPPORT_NEON_BUILD - Success
-- Found ZLIB: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libz.tbd (found version "1.2.11") 
-- Found BZip2: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libbz2.tbd (found version "1.0.6") 
-- Looking for BZ2_bzCompressInit
-- Looking for BZ2_bzCompressInit - found
-- Found OpenAL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenAL.framework  
-- JACK not found, disabling WITH_JACK
CMake Error at build_files/cmake/platform/platform_apple.cmake:86 (message):
  Mac OSX requires pre-compiled libs at:
  '/Users/leon/Blender-git/blender/../lib/darwin_arm64'
Call Stack (most recent call first):
  CMakeLists.txt:938 (include)

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? ``` leon@Leons-MacBook-Air blender % make Configuring Blender in "/Users/leon/Blender-git/build_darwin" ... -- The C compiler identification is AppleClang 12.0.0.12000032 -- The CXX compiler identification is AppleClang 12.0.0.12000032 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detected native architecture arm64. objc[4348]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x2008cc188) and ?? (0x116ddc2b8). One of the two will be used. Which one is undefined. objc[4348]: Class AMSupportURLSession is implemented in both ?? (0x2008cc1d8) and ?? (0x116ddc308). One of the two will be used. Which one is undefined. -- Detected OS X 11.1 and Xcode 12.4 at /Applications/Xcode.app/Contents/Developer -- SDKs Directory: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs -- Detected OSX_SYSROOT: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -- Found Git: /opt/homebrew/bin/git (found version "2.31.1") -- Performing Test SUPPORT_NEON_BUILD -- Performing Test SUPPORT_NEON_BUILD - Success -- Found ZLIB: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libz.tbd (found version "1.2.11") -- Found BZip2: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libbz2.tbd (found version "1.0.6") -- Looking for BZ2_bzCompressInit -- Looking for BZ2_bzCompressInit - found -- Found OpenAL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenAL.framework -- JACK not found, disabling WITH_JACK CMake Error at build_files/cmake/platform/platform_apple.cmake:86 (message): Mac OSX requires pre-compiled libs at: '/Users/leon/Blender-git/blender/../lib/darwin_arm64' Call Stack (most recent call first): CMakeLists.txt:938 (include) ```

In #78710#1149187, @Zandman wrote:
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 M1 Mac, so I'm sorry if this doesn't work. However one of the errors I'm seeing from your build log is Mac 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 run make update in the terminal in the Blender source directory, wait a while for everything to download, then build Blender with make.

It's also possible that GIT/SVN isn't picking up that you're on a M1 Mac 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?

Open a terminal and change your directory to /Users/YOUR_NAME/Blender-git/lib/
Run the command svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin_arm64/
Change the terminal back to /Users/YOUR_NAME/Blender-git/blender/ and run then run the make update and make commands.
If that doesn't work, try deleting the folder /Users/YOUR_NAME/Blender-git/build_darwin/ or /Users/YOUR_NAME/Blender-git/build_darwin_arm64/ then building again with make.
If this isn't working, you may need to open the CMakeCache.txt file (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 M1 Mac, and so may be wrong in this. But I'm hopeful this may help.

In #78710#1149203, @Alaska wrote:
It's also possible that GIT/SVN isn't picking up that you're on a M1 Mac 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?

Open a terminal and change your directory to /Users/YOUR_NAME/Blender-git/lib/

Run the command svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin_arm64/

Change the terminal back to /Users/YOUR_NAME/Blender-git/blender/ and run then run the make update and make commands.

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 db021ee2ea

Haven'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:

In file included from /Users/phil/src/blender-git/blender/extern/audaspace/plugins/openal/OpenALReader.cpp:17:
/Users/phil/src/blender-git/blender/extern/audaspace/plugins/openal/OpenALReader.h:31:10: fatal error: 'alc.h' file not found
#include <alc.h>

I even trashed my lib/ directory, so that I could refetch all dependencies. Did that, plus this and still getting the error:

make update
make

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:

  make full && make update

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 a make update from the Blende repo. That didn't help. I then tried to recreate the Xcode project by doing cmake . -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/667561

ln -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.sdk

In #78710#1155099, @hargettp wrote:
Haven'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:
In file included from /Users/phil/src/blender-git/blender/extern/audaspace/plugins/openal/OpenALReader.cpp:17:
/Users/phil/src/blender-git/blender/extern/audaspace/plugins/openal/OpenALReader.h:31:10: fatal error: 'alc.h' file not found
#include <alc.h>
I even trashed my lib/ directory, so that I could refetch all dependencies. Did that, plus this and still getting the error:
make update
make
Just actually upgraded to macOS 11.3, in case that could have done it. Even after updating Xcode still getting it.

Can'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!

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 (c75b2019e101) 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](https://archive.blender.org/developer/F10068566/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: ![MacBook Pro 2018 Intel - Screenshot.jpg](https://archive.blender.org/developer/F10068573/MacBook_Pro_2018_Intel_-_Screenshot.jpg) ![MacBook Pro Intel 2018 - Screen Space Reflections ON - Blender 2.92.0.jpg](https://archive.blender.org/developer/F10068575/MacBook_Pro_Intel_2018_-_Screen_Space_Reflections_ON_-_Blender_2.92.0.jpg) 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: ![Mac mini M1 2020 - Screenshot.jpg](https://archive.blender.org/developer/F10068577/Mac_mini_M1_2020_-_Screenshot.jpg) ![Mac mini M1 2020 - Screen Space Reflections ON - Blender 2.93.0 Beta.jpg](https://archive.blender.org/developer/F10068579/Mac_mini_M1_2020_-_Screen_Space_Reflections_ON_-_Blender_2.93.0_Beta.jpg) 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*: ![Mac mini M1 2020 - Screen Space Reflections OFF - Blender 2.93.0 Beta.jpg](https://archive.blender.org/developer/F10068581/Mac_mini_M1_2020_-_Screen_Space_Reflections_OFF_-_Blender_2.93.0_Beta.jpg) I did some searching, and [this post on StackExchange ](https://blender.stackexchange.com/questions/209295/why-does-my-m1-macbook-pro-render-scenes-differently-than-my-2016-macbook-pro) 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!

In #78710#1149187, @Zandman wrote:
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?

Today I decided to completely delete the Blender repository and related stuff (the Blender-git folder) 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 the darwin_arm64 libraries 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 Blender make update target used the Intel version. So the call to platform.machine() returned x86_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 b158477551

In #78710#1161835, @CookItOff wrote:
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.

Where 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'

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

macOS: Support arm64 #78710