taichi: Failed to run GGUI on macOS

Describe the bug I couldn’t run all GGUI examples on my mac.

To Reproduce I build Taichi source code successfully from source on macOS Monterey 12.3.1, Vulkan Instance Version: 1.3.204. I tried to run GGUI examples but failed.

Log/Screenshots

$ python  python/taichi/examples/ggui_examples/mpm3d_ggui.py                          
[Taichi] version 0.9.3, llvm 10.0.0, commit c1fef8e3, osx, python 3.8.11
[Taichi] Starting on arch=vulkan
2022-04-11 20:32:13.656 python[9138:70780] -[__NSCFString countByEnumeratingWithState:objects:count:]: unrecognized selector sent to instance 0x600001e28e70
[1]    9138 segmentation fault  python python/taichi/examples/ggui_examples/mpm3d_ggui.py

Additional comments ti diagnose output:

[Taichi] version 0.9.3, llvm 10.0.0, commit c1fef8e3, osx, python 3.8.8

*******************************************
**      Taichi Programming Language      **
*******************************************

Docs:   https://docs.taichi.graphics/
GitHub: https://github.com/taichi-dev/taichi/
Forum:  https://forum.taichi.graphics/

Taichi system diagnose:

python: 3.8.8 (default, Apr 13 2021, 12:59:45) 
[Clang 10.0.0 ]
system: darwin
executable: /Users/yupeng/opt/anaconda3/bin/python
platform: macOS-10.16-x86_64-i386-64bit
architecture: 64bit 
uname: uname_result(system='Darwin', node='192.168.1.4', release='21.4.0', version='Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64', machine='x86_64', processor='i386')
locale: zh_CN.UTF-8
PATH: /Users/yupeng/opt/anaconda3/bin:/Users/yupeng/code/opensource/taichi-llvm-10.0.0-macos/bin:/Users/yupeng/code/opensource/taichi/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/CMake.app/Contents/bin:/Library/TeX/texbin:/opt/X11/bin:/Library/Apple/usr/bin:/opt/local/bin
PYTHONPATH: ['/Users/yupeng/opt/anaconda3/bin', '/Users/yupeng/code/opensource/taichi/python', '/Users/yupeng/code/opensource/taichi', '/Users/yupeng/opt/anaconda3/lib/python38.zip', '/Users/yupeng/opt/anaconda3/lib/python3.8', '/Users/yupeng/opt/anaconda3/lib/python3.8/lib-dynload', '/Users/yupeng/.local/lib/python3.8/site-packages', '/Users/yupeng/opt/anaconda3/envs/taichi_env/lib/python3.8/site-packages/astor-0.8.1-py3.8.egg', '/Users/yupeng/opt/anaconda3/envs/taichi_env/lib/python3.8/site-packages/colorama-0.4.4-py3.8.egg', '/Users/yupeng/opt/anaconda3/envs/taichi_env/lib/python3.8/site-packages/sourceinspect-0.0.4-py3.8.egg', '/Users/yupeng/opt/anaconda3/envs/taichi_env/lib/python3.8/site-packages/dill-0.3.4-py3.8.egg', '/Users/yupeng/opt/anaconda3/lib/python3.8/site-packages/astunparse-1.6.3-py3.8.egg', '/Users/yupeng/opt/anaconda3/lib/python3.8/site-packages/wheel-0.37.1-py3.8.egg', '/Users/yupeng/opt/anaconda3/lib/python3.8/site-packages', '/Users/yupeng/opt/anaconda3/lib/python3.8/site-packages/aeosa', '/Users/yupeng/opt/anaconda3/lib/python3.8/site-packages/locket-0.2.1-py3.8.egg']

`lsb_release` not available: [Errno 2] No such file or directory: 'lsb_release'


import: <module 'taichi' from '/Users/yupeng/code/opensource/taichi/python/taichi/__init__.py'>

cc: False
cpu: True
metal: True
opengl: False
cuda: False
vulkan: True

`glewinfo` not available: [Errno 2] No such file or directory: 'glewinfo'

`nvidia-smi` not available: [Errno 2] No such file or directory: 'nvidia-smi'
[Taichi] version 0.9.3, llvm 10.0.0, commit c1fef8e3, osx, python 3.8.8

[Taichi] version 0.9.3, llvm 10.0.0, commit c1fef8e3, osx, python 3.8.8
[Taichi] Starting on arch=x64

[W 04/11/22 20:51:51.638 93507] [misc.py:adaptive_arch_select@743] Arch=[<Arch.opengl: 7>] is not supported, falling back to CPU
[Taichi] version 0.9.3, llvm 10.0.0, commit c1fef8e3, osx, python 3.8.8
[Taichi] Starting on arch=x64

[W 04/11/22 20:51:52.812 93560] [misc.py:adaptive_arch_select@743] Arch=[<Arch.cuda: 5>] is not supported, falling back to CPU
[Taichi] version 0.9.3, llvm 10.0.0, commit c1fef8e3, osx, python 3.8.8
[Taichi] Starting on arch=x64

[Taichi] version 0.9.3, llvm 10.0.0, commit c1fef8e3, osx, python 3.8.8

*******************************************
**      Taichi Programming Language      **
*******************************************

Docs:   https://docs.taichi.graphics/
GitHub: https://github.com/taichi-dev/taichi/
Forum:  https://forum.taichi.graphics/

Running example minimal ...
[Taichi] Starting on arch=x64
42.0
>>> Running time: 0.30s
42

Consider attaching this log when maintainers ask about system information.
>>> Running time: 13.38s

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 23 (9 by maintainers)

Most upvoted comments

Should we submit a bug report to MoltenVK for this? Can you pin down the MoltenVK version & specific Intel GPU sku?

The solution is https://github.com/KhronosGroup/MoltenVK/issues/1580#issuecomment-1122965111 and https://github.com/KhronosGroup/MoltenVK/pull/1593.

TLTR: Solution 1: We could download a newly built libmoltenvk.dylib on my Mac and replace the old one in Taichi. The download link is here Solution 2: This problem started from MoltenVK 1.1.7. So Taichi could brew install MoltenVK 1.1.6 or an older version to solve this problem.

我也遇到了一样的问题,我的硬件和他一摸一样

Thanks, @bobcao3. MoltenVK versions 1.8.8, 1.8.9 and the master branch build are all not working. My GPU is Intel® Iris™ Plus Graphics 1546 MB which supports Metal GPUFamily macOS 2.

Can you get the specific sku? e.g. Iris Plus 650, or just the specific CPU sku

Thanks, @bobcao3. MoltenVK versions 1.8.8, 1.8.9 and the master branch build are all not working. My GPU is Intel® Iris™ Plus Graphics 1546 MB which supports Metal GPUFamily macOS 2.

Cool! Once you finished testing on another mac, let’s submit this (better with a small repro using Vulkan) to https://github.com/KhronosGroup/MoltenVK/issues

Hi @k-ye, @bobcao3.

The vkInstance is created twice in Taichi. The first time is to check_vulkan_device and the temporarily created instance is destroyed after checking the Vulkan device. The second time is to create the real instance we would use.

On my mac, the first pass works fine. But not for the second time. It crashes here because _mtlDevice.counterSets becomes a NSString object and not NSArray<id<MTLCounterSet>>* (it should be according to Apple’s Metal API) anymore.

I wonder if it has something to do with a memory leak. The destruction is not complete after the first time creating vkInstane. Do you have some inputs about this, @bobcao3?

Besides, I would also try to imitate the two-time creation based on a worked Vulkan demo according to the Vulkan tutorial.

BTW, my GPU card is Intel® Iris™ Plus Graphics. Two colleagues of mine whose Macbook GPU is also Intel tried to run GGUI and it runs normally.