Blender 2.8+ is not running inside an amd64 container on M1 Mac
Closed, ArchivedPublic
Actions

Description

System Information
Operating system: MacOS Big Sur 11.5.1
Graphics card: Apple M1
Docker Desktop: 4.1.1 (69879)

Docker Image
Operating system: Ubuntu 18.04.6 LTS x86_64
Graphics card: -----

Blender Version
blender-2.79-linux-glibc219-x86_64 ==> ✅ Works
blender-2.93.5-linux-x64 ==> ❌ Fails

Short description of error
Blender versions 2.8+ do not work inside docker containers on M1 Mac

Exact steps for others to reproduce the error
I provided a docker setup to spin up a container for testing the behavior...

You need:
✅ M1 Mac
✅ Docker Desktop 4.1.1 (69879)

Setup the Container:

Unzip the attached file
In a terminal go to the unzipped folder
run source build-and-launch.sh to build the image and spin up a container
open a browser and go to http://localhost:6901
login using password pass
see the README.txt on the Desktop you just logged into
>> Follow the README instructions <<

(to install stuff inside the container run su and use password pass before installation)

I tested the commands ./blender --version and ./blender-softwaregl in this container from blender version 2.79 all the way up to 2.93.5.

It is worth mentioning that the commands stopped executing delayed:

✅ 2.79
     ✅ blender --version
     ✅ blender-softwaregl

❎ 2.80
     ✅ blender --version
     ❌ blender-softwaregl

❎ 2.81
     ✅ blender --version
     ❌ blender-softwaregl

❌ 2.82
     ❌ blender --version
     ❌ blender-softwaregl

❌ 2.83.7
     ❌ blender --version
     ❌ blender-softwaregl

❌ 2.93
     ❌ blender --version
     ❌ blender-softwaregl

❌ blender-3.0.0-beta+v30.7b530c609611-linux.x86_64-release
     ❌ blender --version
     ❌ blender-softwaregl

When failing the error message is:

ArchError: Could not find cpu MHz in /proc/cpuinfo
  Function: Arch_InitTickTimer
      File: /home/sergey/Developer/build_linux/deps/build/usd/src/external_usd/pxr/base/lib/arch/timing.cpp
      Line: 133
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

By investigating on the /proc/cpuinfo file it seems like intel cpus provide the clock speed in cpu MHz while on arm machines (e.g. raspberry pi, M1) the file contains a field for BogoMIPS (a linux kernel unit for cpu speed, regarding to wikipedia)

Since the latest version of Blender runs on the exact same container when mounted on a Intel host machine I assume that at some point there should be a catch for missing cpu MHz and a check for existing BogoMIPS in the /proc/cpuinfo

Here is the /proc/cpuinfofile of the emulated x86 container on M1 therefore with BogoMIPS and without cpu MHz:

processor       : 0
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint
CPU implementer : 0x00
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0x000
CPU revision    : 0

processor       : 1
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint
CPU implementer : 0x00
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0x000
CPU revision    : 0

processor       : 2
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint
CPU implementer : 0x00
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0x000
CPU revision    : 0

processor       : 3
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint
CPU implementer : 0x00
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0x000
CPU revision    : 0

Thank you,
all the best,
Clemens

blender-bug-report-202111091146.zip4 MBDownload

Related Objects

Mentioned Here: M1: Bevel Tool Toolbar Layout - Multiple Overflow Popovers

Event Timeline

Clemens Holleis (CH85) created this task.Nov 9 2021, 12:30 PM

Clemens Holleis (CH85) updated the task description. (Show Details)Nov 9 2021, 12:33 PM

Clemens Holleis (CH85) updated the task description. (Show Details)

Georg Kothmeier (tschoartschi) added a subscriber: Georg Kothmeier (tschoartschi).Nov 9 2021, 12:51 PM

What is the contents of /proc/cpuinfo?

This would need to be solved either in Docker or in the Pixar USD library. It's not obvious to me which one is wrong, or if it's a case of mismatched conventions where either could be fixed.
https://github.com/PixarAnimationStudios/USD/blob/release/pxr/base/arch/timing.cpp

I'm not sure we should handle this issue as part of the Blender project.

USD didn’t support ARM on Linux until version 21.08.
See:
https://github.com/PixarAnimationStudios/USD/pull/1453
https://github.com/PixarAnimationStudios/USD/blob/release/CHANGELOG.md

Blender is currently building with version 21.02.
https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/cmake/versions.cmake$429

In T92956#1251328, @Brecht Van Lommel (brecht) wrote:

I'm not sure we should handle this issue as part of the Blender project.

Update the library for Blender 3.1+?

Clemens Holleis (CH85) updated the task description. (Show Details)Nov 10 2021, 9:30 AM

In T92956#1251328, @Brecht Van Lommel (brecht) wrote:

What is the contents of /proc/cpuinfo?

I added the contents of the file to the description

Clemens Holleis (CH85) updated the task description. (Show Details)Nov 10 2021, 9:36 AM

Clemens Holleis (CH85) updated the task description. (Show Details)Nov 10 2021, 1:27 PM

The problem is USD assumes lowercase bogomips instead of BogoMIPS. From a quick search, I only saw lowercase for AMD/Intel processors on Linux. The number 48.0 also seems to be off by a factor of ~100 (0.024GHz instead of 2.4GHz).

We can submit a patch to the USD project to fix this, so it will be solved for a future Blender release. I don't think we will update the USD library for Blender 2.93 or 3.0, since running Blender under Docker is not something we officially support.

You could try submitting a bug report to Docker also, since if they improve compatibility with a real Linux install here it will make previous Blender versions work.

In T92956#1251591, @Evan Wilson (EAW) wrote:

USsD didn’t support ARM on Linux until version 21.08.

That's not relevant to this issue, it's running the x86_64 timing code which is unchanged.

In T92956#1251927, @Brecht Van Lommel (brecht) wrote:

The problem is USD assumes lowercase bogomips instead of BogoMIPS. From a quick search, I only saw lowercase for AMD/Intel processors on Linux. The number 48.0 also seems to be off by a factor of ~100 (0.024GHz instead of 2.4GHz).

I checked the spelling/casing on a raspberry pi (since it's the only ARM processor other than the M1 I have access to) and it matches the one in docker BogoMIPS (see below). Also the numbers are in a similar range, being 38.40 on the pi and 48.0 in the M1 docker container.

Raspberry's system information:

  `.::///+:/-.        --///+//-:``    root@raspberrypi 
 `+oooooooooooo:   `+oooooooooooo:    ---------------- 
  /oooo++//ooooo:  ooooo+//+ooooo.    OS: Raspbian GNU/Linux 10 (buster) armv7l 
  `+ooooooo:-:oo-  +o+::/ooooooo:     Host: Raspberry Pi 2 Model B Rev 1.1 
   `:oooooooo+``    `.oooooooo+-      Kernel: 5.10.63-v7+ 
     `:++ooo/.        :+ooo+/.`       Uptime: 56 mins 
        ...`  `.----.` ``..           Packages: 2144 (dpkg) 
     .::::-``:::::::::.`-:::-`        Shell: bash 5.0.3 
    -:::-`   .:::::::-`  `-:::-       Resolution: 1920x1080 
   `::.  `.--.`  `` `.---.``.::`      WM: Openbox 
       .::::::::`  -::::::::` `       Theme: Adwaita [GTK3] 
 .::` .:::::::::- `::::::::::``::.    Icons: Adwaita [GTK3] 
-:::` ::::::::::.  ::::::::::.`:::-   Terminal: lxterminal 
::::  -::::::::.   `-::::::::  ::::   CPU: BCM2835 (4) @ 900MHz 
-::-   .-:::-.``....``.-::-.   -::-   Memory: 178MiB / 923MiB 
 .. ``       .::::::::.     `..`..
   -:::-`   -::::::::::`  .:::::`                             
   :::::::` -::::::::::` :::::::.
   .:::::::  -::::::::. ::::::::
    `-:::::`   ..--.`   ::::::.
      `...`  `...--..`  `...`
            .::::::::::
             `.-::::-`

====================================================================
>>> lscpu
Architecture:        armv7l
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               5
Model name:          Cortex-A7
Stepping:            r0p5
CPU max MHz:         900,0000
CPU min MHz:         600,0000
BogoMIPS:            38.40
Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

contents of the raspberry's /proc/cpuinfo

processor	: 0
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 57.60
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 1
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 57.60
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 2
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 57.60
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 3
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 57.60
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

Hardware	: BCM2835
Revision	: a01041
Serial		: 00000000bdf3d38c
Model		: Raspberry Pi 2 Model B Rev 1.1

Right, ARM uses a different convention but I would think the intent of Docker is to emulate x86_64 as closely as possible when running an x86_64 Ubuntu.

In T92956#1252407, @Brecht Van Lommel (brecht) wrote:

Right, ARM uses a different convention but I would think the intent of Docker is to emulate x86_64 as closely as possible when running an x86_64 Ubuntu.

Yes I also came to the conclusion that the emulated container should provide a modified cpuinfo file resembling a x86 architecture. Even the lscpu command lists the architecture as x86 (see below) so the cpuinfo should also look like that.

I will report this false behavior to docker and will link this ticket there as well – so here we can consider it done?

# lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       0x00
Model:                           0
Stepping:                        0x0
BogoMIPS:                        48.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint

I reported the issue to docker here:
https://github.com/docker/for-mac/issues/6047

Since the issue seems to be caused by the emulation with QEMU, the issue is now reported here:
https://gitlab.com/qemu-project/qemu/-/issues/750

Is there any bug in Blender? If this issue is exclusive to qemu I would close this report.

Yes, I think it can be closed here.

Blender 2.8+ is not running inside an amd64 container on M1 MacClosed, ArchivedPublicActions

Description

Related Objects

Event Timeline

Blender 2.8+ is not running inside an amd64 container on M1 Mac
Closed, ArchivedPublic
Actions