Page MenuHome

Eevee ambient occlusion is incorrect on M1 macMini
Closed, ResolvedPublic

Description

System Information
Operating system: macOS-11.2.3-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Apple 4.1 Metal - 71.0.7

Blender Version
Broken version: 2.93.0 Beta, branch: master (modified), commit date: 2021-04-19 10:12, hash: rB6dffdb02fa2a
Note: Earlier versions I tested (running with Rosetta 2) all have this bug.

Short description of error
Eevee ambient occlusion is incorrect on M1 macMini.

Exact steps for others to reproduce the error
From default scene:

  • add a plane
  • scale it 10 times
  • move it down 1 unit
  • switch to material preview or rendered viewport shading
  • enable ambient occlusion
  • to best see the issue, set its parameters to [ 1.0, 1.0, 0.0, false, false ]
  • issue already visible
  • render image to still see it

Note: Every file, every combination of settings produce this issue to some extent.

Event Timeline

I can confirm this issue is happening on Apple Silicon Macs. I'm noticing it on my 2020 Mac mini M1 and it affects both the 2.92.0 release and the latest arm64 2.93.0 Beta (c75b2019e101).

Here's a .blend file I created following the steps above to reproduce the error:

On a 2018 MacBook Pro Intel, running the 2.92.0 release on macOS 10.15.7, this is what the viewport and renders of the above .blend file look like, as expected:

On the Mac mini M1, running the arm64 2.93.0 Beta (c75b2019e101) on macOS 11.3.1, this is what the viewport and renders look like. The glitching is very noticeable.

On the Mac mini M1, running the 2.92.0 release via Rosetta 2 on macOS 11.3.1, this is what the viewport and renders look like. The glitching is noticeable in the viewport, but the render less so, although the render is still incorrect compared to the render from the Intel MacBook Pro above.

Adding MacOS as a tag here since you are facing the problem on Mac.

Btw I am not able to reproduce it on Windows.


System Information:

Operating system : Windows-10-10.0.18362-SP0 64 Bits
Graphics card : AMD Radeon(TM) 535 ATI Technologies .
Ankit Meel (ankitm) changed the task status from Needs Triage to Confirmed.May 28 2021, 2:01 PM

There's no M1 in triaging team, but confirming due to easy steps, and active reporters.

it would be neat to have 'teamviewer' or something like that be used to confirm issues / even test builds etc on willing users machines

I'd donate an account of this M1 cloud server if it would get used to fix Blender M1 bugs:
https://www.scaleway.com/en/hello-m1/

Any way we can move this forward? (not complaining, but I'm just ignorant of the process)

This is a critical bug for any M1 users who are planning on EEVEE as a final render option.

I was able to build Blender from source on my M1 MacMini without any issues. I started experimenting with the Eevee AO shader without success on figuring out what this issue is. I do not have enough time to properly look into it though. If anyone has the faintest idea what this is caused by, let me know, and I will try to squeeze in the time to check it. My idea was that it might have something to do with what the depth component of the framebuffer samples outside its borders.

Confirmed on M1 iMacs and Blender 2.93.1

System Information
Operating system: macOS-11.4-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Apple 4.1 Metal - 71.6.4

Blender Version
Broken: version: 2.93.1, branch: master, commit date: 2021-06-22 05:57, hash: rB1b8d33b18c2f
Worked: (newest version of Blender that worked as expected)

Short description of error
Different AO results between apple M1 and Intel machines.
Opening the same file in rendered on EEVEE on an M1 machine gives different results from an Intel one.
See attached image for visual reference


Please note that both Rosetta and native ARM are consistent in this result.

Exact steps for others to reproduce the error
Set view in rendered. The effect becomes move visible changing ambient occlusion distance and factor values.
Based on attached .blend file

I would like to emphasise how this is currently a 100% pipeline breaker in our production as we heavily rely on EEVEE. Is there any chance to get an update on this? Thanks for all your hard work!

Yes, this has been an issue for about 6 months and has had no progress unfortunately. Could use some direction on how the community could help diagnose at least. This stops me from using EEVEE at all as a rendering engine.

Clément Foucault (fclem) triaged this task as High priority.

This will be tackled next week.

Thanks a lot Clément! Let me know if there is anything i could test for you!

Hi!
I tested this with the latest build from builder.blender.org on my M1 iMac, and I have found no problems!
Thanks for the Fix!

Thank you, @Clément Foucault (fclem)!! Your fix works great. On 2.93.5RC, renders on Intel and Apple Silicon match each other. It has also resolved T88241: macOS: Eevee Screen Space Reflections are broken on arm64, which can now be closed too!