[AppleSilicon] Building PrusaSlicer on new Apple ARM based Mac's

xarbit commented 3 years ago

I opened this ticket to keep track of everything and my findings when building on the M1 (ARM) chip from Apple. I would appreciate any help and support from the community.

with only some minor changes, you can now build and run PrusaSlicer on AppleSilicon.

[x] build static Dependencies in dep/ -> branch: https://github.com/prusa3d/PrusaSlicer/pull/5313 (merged)
[x] build PrusaSlicer with static Dependencies -> [macOS guide ] (https://github.com/prusa3d/PrusaSlicer/blob/master/doc/How%20to%20build%20-%20Mac%20OS.md)
[x] needed patch or update to v3.1.4 of wxWidgets as prusa3D/wxWidgets (v3.1.3-patched) is outdated and will not run. (thanks @obelisk)-> https://github.com/prusa3d/PrusaSlicer/pull/5316 , https://github.com/prusa3d/PrusaSlicer/issues/5322 (merged)

Unofficial Package / App bundle for AppleSilicon Note: This package is unofficial, dirty packed, untested and absolutely not supported by Prusa3D atm. Do not report any bugs outside of this ticket and use at you're own risk. https://mega.nz/file/GfR03Tbb#kOf_3SfIvvnrzGxVnmbIqvrhsINuLqZj9W0_Tmo1od4

Building all depencies now work: MR: (WIP) https://github.com/prusa3d/PrusaSlicer/pull/5313

Update 2020.11.28 @obelisk was able to successfully build PrusaSlicer using native homebrew. Instructions: https://github.com/prusa3d/PrusaSlicer/issues/5179#issuecomment-734962192

Update 2020.11.25: I received my MacBook Pro M1 yesterday, I went ahead and tried to build PrusaSlicer. Built CMake and gettext from source without issues. When trying to build the dependencies within PrusaSlicer. It fails on boost. https://github.com/prusa3d/PrusaSlicer/issues/5124#issuecomment-733544538

W3DRK commented 3 years ago

This is excellent news and I'd be happy to test any of your future builds. I received my M1 MacBook Pro on the 17th and so far it completely lives up to the hype.

xarbit commented 3 years ago

This is excellent news and I'd be happy to test any of your future builds. I received my M1 MacBook Pro on the 17th and so far it completely lives up to the hype.

thanks, how is PrusaSlicer running under Rosetta2?

W3DRK commented 3 years ago

thanks, how is PrusaSlicer running under Rosetta2?

So far it works perfectly. And it seems to run quicker than it did on my 2017 i5 MacBook Pro both when manipulating objects on the print surface and slicing.

kr15uk commented 3 years ago

Can confirm that cheapest M1 MacBook Air feels snappier than my 2019 i7 MacBook Pro. Been using beta3 for almost a week now (since 17/Nov), upgraded to beta4 now - so far so good.

Happy to test native build when ready. Ta

K

obelisk commented 3 years ago

~Having issues with TBB blocking the build, will update if I figure it out.~

Fixed TBB, but QT doesn't build on M1 yet (at least not in brew or the mainline branch I pulled.) This blocks the build of PrusaSlicer. I know the QT community has patches available but I haven't succeeded in finding exactly what branch and cherrypicks I need to do. I'll update here when and if I get it working.

bubnikv commented 3 years ago

but QT doesn't build on M1 yet

wxWidgets?

I'll update here when and if I get it working.

Thanks

xarbit commented 3 years ago

@obelisk are you using native brew? I am avoiding brew until it is officially released, if you are not using native ARM homebrew then you are mixing rosetta2 (intel) with ARM. So until then, building CMake and gettext from source works just fine on the M1 without an issue.

Following the macOS guide here in the wiki, that is all you need to start building the rest of the dependencies in the dep folder.

For me, its stops when trying to build boost (deps-macos.cmake). everything in deps-unix-common.cmake which is built before (including TBB and Co.) seemed to have worked fine.

obelisk commented 3 years ago

I am using native arm brew so there should be no mixing. Install boost from brew appears to have worked fine. TBB had an issue but I patched the Cmake file to at least get some of the libs to work and we'll see if the bites me later.

Next up was libpng which I again installed via brew and it seemed to work. The last step I got to before having to sleep last night was Cereal. ~Cereal has QT5 as a dep and it needs to be build from scratch because there are no arm64 bottles available (as far as I know at least).~

The night prior I'd also had issues building QT5 when I was investigating the OBS build system and that was when I learned it should be possible to build QT5 but I haven't managed it yet. I will be trying more today and will update here if I get a native build working.

For anyone who is trying to use brew, what I've done is the custom location install in /opt/homebrew and then symlinked /usr/local/include and /usr/local/bin to the /opt/homebrew ones (I am aware that this is bad and will cause issues later but it was the easiest way to get all the reps found while testing).

bubnikv commented 3 years ago

Cereal has QT5

Cereal is header only. It should not require QT5. USCiLab/cereal: A C++11 library for serialization (github.com) https://github.com/USCiLab/cereal

pá 27. 11. 2020 v 18:17 odesílatel Mitchell Grenier < notifications@github.com> napsal:

I am using native arm brew so there should be no mixing. Install boost from brew appears to have worked fine. TBB had an issue but I patched the Cmake file to at least get some of the libs to work and we'll see if the bites me later.

Next up was libpng which I again installed via brew and it seemed to work. The last step I got to before having to sleep last night was Cereal. Cereal has QT5 as a dep and it needs to be build from scratch because there are no arm64 bottles available (as far as I know at least).

The night prior I'd also had issues building QT5 when I was investigating the OBS build system and that was when I learned it should be possible to build QT5 but I haven't managed it yet. I will be trying more today and will update here if I get a native build working.

For anyone who is trying to use brew, what I've done is the custom location install in /opt/homebrew and then symlinked /usr/local/include and /usr/local/bin to the /opt/homebrew ones.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/5179#issuecomment-734927342, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI7GXHBTYSPEKU7RUY3SR7NJDANCNFSM4TYSULLA .

obelisk commented 3 years ago

Interesting! When I tried using brew it wanted to install QT5 so I guess brew is just wrong. I'll keep at it.

EDIT: I might have been confusing Cereal with cgal (it was 4am for me, I probably just remembered wrong).

bubnikv commented 3 years ago

It may be a different Cereal.

pá 27. 11. 2020 v 18:35 odesílatel Mitchell Grenier < notifications@github.com> napsal:

Interesting! When I tried using brew it wanted to install QT5 so I guess brew is just wrong. I'll keep at it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/5179#issuecomment-734932840, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI4J4NFQ4TIZ67YBEJDSR7PO5ANCNFSM4TYSULLA .

bubnikv commented 3 years ago

There may be multiple things (libraries, applications) with the same name around.

pá 27. 11. 2020 v 18:53 odesílatel Vojtech Bubnik vojtech.bubnik@prusa3d.cz napsal:

It may be a different Cereal.

pá 27. 11. 2020 v 18:35 odesílatel Mitchell Grenier < notifications@github.com> napsal:

Interesting! When I tried using brew it wanted to install QT5 so I guess brew is just wrong. I'll keep at it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/5179#issuecomment-734932840, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI4J4NFQ4TIZ67YBEJDSR7PO5ANCNFSM4TYSULLA .

obelisk commented 3 years ago

Good news everyone:

I'm writing out instructions now

obelisk commented 3 years ago

Notes:

I haven't tested it,
There was an error about virtual functions that I just hacked around
There are assertions that fire on start up that I had to ignore

How to get it to build:

Get brew working in /opt/homebrew. You should install it in /opt/homebrew because the user cannot own the /usr/local folder anymore and this is what I read is the plan for homebrew going forward. Link lib and include as I said above. I know this is bad (because installing things to /usr/local/lib or include will confuse brew), but this should be just a temporary solution.

Install Cmake via brew
Then what I did is follow the build steps of making the build dir then running cmake .. and whenever there is a missing dependency installing it via brew. There are a couple exceptions here: qt, and wxwidgets which I'll cover below.
When Cmake finally succeeds, you're done step 1 of 3.
Next is to patch: src/slic3r/GUI/GUI_App.hpp and remove the override keyword on line 256, and 257. This is wrong but I haven't had time to dig through the code and figure out what the right thing is.
Now when you make (make -j8 PrusaSlicer) you're going to see more warnings than you thought possible but it's ok until it gets to linking.
PrusaSlicer tries to link against the system icu library which is not what boost is linked against so it'll fail.
You finally need to add: -L/opt/homebrew/opt/icu4c/lib -licuuc -licui18n -L/opt/homebrew/lib to build/src/CMakeFiles/PrusaSlicer.dir/link.txt
Rerun Cmake and it should work.

Edit: Forgot to add the steps to fix QT and wxwidgets:

QT: brew edit qt add -skip qtwebengine and remove -proprietary-codecs in args on line 52
wxwidgets: brew install --HEAD wxwidgets. Otherwise the installed version is too old and PrusaSlicer won't build

I'm sorry if I've forgotten steps, I hope this is enough that people can begin testing PrusaSlicer on AppleSilicon computers, finding bugs and issues while we work out a better build system.

I will post with more updates if and when I have them. Happy printing!

bubnikv commented 3 years ago

Mitch,

would you please compare slicing times of your apple build against our provided Intel build? We would like to know the emulation penalty to decide whether we want to hurry up with the Apple build.

Thank you.

pá 27. 11. 2020 v 20:33 odesílatel Mitchell Grenier < notifications@github.com> napsal:

Notes:

I haven't tested it,

There was an error about virtual functions that I just hacked around

There are assertions that fire on start up that I had to ignore

How to get it to build:

Get brew working in /opt/homebrew. You should install it in /opt/homebrew because the user cannot own the /usr/local folder anymore and this is what I read is the plan for homebrew going forward. Link lib and include as I said above. I know this is bad (because installing things to /usr/local/lib or include will confuse brew), but this should be just a temporary solution.

Install Cmake via brew

Then what I did is follow the build steps of making the build dir then running cmake .. and whenever there is a missing dependency installing it via brew. There are a couple exceptions here: qt, and wxwidgets which I'll cover below.

When Cmake finally succeeds, you're done step 1 of 3.

Next is to patch: src/slic3r/GUI/GUI_App.hpp and remove the override keyword on line 256, and 257. This is wrong but I haven't had time to dig through the code and figure out what the right thing is.

Now when you make you're going to see more warnings than you thought possible but it's ok until it gets to linking.

PrusaSlicer tries to link against the system icu library which is not what boost is linked against so it'll fail.

You finally need to add: -L/opt/homebrew/opt/icu4c/lib -licuuc -licui18n -L/opt/homebrew/lib to build/src/CMakeFiles/PrusaSlicer.dir/link.txt

Rerun Cmake and it should work.

I'm sorry if I've forgotten steps, I hope this is enough that people can begin testing PrusaSlicer on AppleSilicon computers, finding bugs and issues while we work out a better build system.

I will post with more updates if and when I have them. Happy printing!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/5179#issuecomment-734962192, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI6YFRTN65L3MTPOHV3SR75H3ANCNFSM4TYSULLA .

obelisk commented 3 years ago

Which model would you like me to benchmark?

Currently looking at PrusaSlicer --slice and slicing a rook model

obelisk commented 3 years ago

Apple Silicon Build:

➜  src git:(master) ✗ for i in {1..10}; do time ./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null; done
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  18.36s user 1.20s system 555% cpu 3.523 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  17.72s user 1.52s system 532% cpu 3.611 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  16.00s user 1.14s system 541% cpu 3.163 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  16.86s user 1.08s system 549% cpu 3.267 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  15.78s user 1.00s system 534% cpu 3.138 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  15.44s user 0.85s system 541% cpu 3.005 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  15.52s user 1.19s system 530% cpu 3.150 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  16.55s user 1.35s system 538% cpu 3.322 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  16.41s user 1.69s system 524% cpu 3.453 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  15.69s user 1.35s system 523% cpu 3.258 total

Intel Build (2.3.0 Alpha 4):

➜  MacOS for i in {1..10}; do time ./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null; done
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  29.25s user 2.16s system 599% cpu 5.243 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  23.02s user 1.72s system 575% cpu 4.301 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  22.41s user 1.88s system 578% cpu 4.199 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  22.28s user 0.99s system 574% cpu 4.050 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  23.26s user 1.41s system 580% cpu 4.251 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  23.43s user 2.08s system 576% cpu 4.427 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  20.75s user 1.32s system 556% cpu 3.966 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  22.20s user 1.27s system 577% cpu 4.066 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  22.79s user 1.31s system 574% cpu 4.198 total
./PrusaSlicer --slice /Users/obelisk/Downloads/rook2_fixed_2.obj > /dev/null  23.27s user 1.66s system 579% cpu 4.299 total

This excludes the first run which is always slower because Rosetta 2 does translation on the first run.

Platform	Average Total Time
Apple Silicon	3.289s
Intel	4.300s

(3.289/4.300) = 0.76488

Conclusion If my math is right, the native build is about 25% faster in this test (is that how you stats)?

obelisk commented 3 years ago

CPU utilization is also looks like its lower on the Apple Silicon build

W3DRK commented 3 years ago

I've followed your instructions closely and keep getting hung up building the dependencies...specifically dep_PNG.

Here's where it fails....

[ 43%] Performing build step for 'dep_PNG' [ 34%] Built target genfiles [ 36%] Building C object CMakeFiles/png_static.dir/arm/arm_init.c.o /Users/dieter/Development/PrusaSlicer/deps/build/dep_PNG-prefix/src/dep_PNG/arm/arm_init.c:48:4: error: "PNG_ARM_NEON_FILE undefined: no support for run-time ARM NEON checks" error "PNG_ARM_NEON_FILE undefined: no support for run-time ARM NEON checks" /Users/dieter/Development/PrusaSlicer/deps/build/dep_PNG-prefix/src/dep_PNG/arm/arm_init.c:85:27: error: implicit declaration of function 'png_have_neon' is invalid in C99 [-Werror,-Wimplicit-function-declaration] no_neon = !png_have_neon(pp); ^

obelisk commented 3 years ago

@W3DRK If you have brew working, try installing it with brew first as it worked for me. If that doesn't work you could also try cloning the libpng repo and doing the build process in there.

Follow the steps for untar anywhere here. Somewhere on the homebrew GitHub I saw that /opt/homebrew was recommended so that's what I used.

W3DRK commented 3 years ago

@W3DRK If you have brew working, try installing it with brew first as it worked for me. If that doesn't work you could also try cloning the libpng repo and doing the build process in there.

Follow the steps for untar anywhere here. Somewhere on the homebrew GitHub I saw that /opt/homebrew was recommended so that's what I used.

Thanks, I actually tickled it into building by commenting out the offending NEON detection code. Now I seem to be hung up building GMP. Configure barfs because clang doesn't support arch armv7-a.

Should it be using GCC instead, assuming that even supports Apple Silicon?

Note I have the native Apple Silicon Homebrew installed in /opt/homebrew...

W3DRK commented 3 years ago

Nevermind I got it, I missed you need to use brew install -s for Apple Silicon!

bubnikv commented 3 years ago

@obelisk thanks for your evaluation. It is highly appreciated.

If my math is right, the native build is about 25% faster in this test (is that how you stats)?

Roughly. You may run the slicer with a higher log level (the --loglevel param or SLIC3R_LOGLEVEL env), then you will see timestamps for the various slicing steps, thus you may subtract for example the time to load from the hard drive. But your test is sound as you have started the process multiple times, so everything was in RAM caches already.

We will do the ARM native build, but the time is running towards the 2.3 final release, so we may not manage for 2.3 yet. 25% drop in performance is not so pressing for us to have to release the native build quickly.

bubnikv commented 3 years ago

Thanks, we shall get the ARM Mac the next week.

so 28. 11. 2020 v 15:30 odesílatel Jason Scurtu notifications@github.com napsal:

I created a MR, which is still an WIP. currently, this fixes the libpng error (PNG_ARM_NEON_FILE undefined) without needing to install from brew. which is also what brew is using.

5305 https://github.com/prusa3d/PrusaSlicer/pull/5305

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/5179#issuecomment-735237669, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI26KUZPGYZM35ZEG2DSSECPVANCNFSM4TYSULLA .

xarbit commented 3 years ago

Thanks, we shall get the ARM Mac the next week. so 28. 11. 2020 v 15:30 odesílatel Jason Scurtu notifications@github.com napsal: …

no problem.. I am still trying a few things out..

xarbit commented 3 years ago

here is my branch again, which seems to work for the depencies: https://github.com/prusa3d/PrusaSlicer/pull/5313

xarbit commented 3 years ago

now following the official macOS guide using my branch works :-) .

I had to build PrusaSlicer without tests as they failed.

cmake .. -DCMAKE_PREFIX_PATH="$PWD/../deps/build/destdir/usr/local" -DSLIC3R_BUILD_TESTS=OFF

Other then that, the whole build was successful, starting PrusaSlicer with ./PrusaSlicer in the src dir, will start but quit after showing the splash screen with the following error:

src/prusa-slicer
[2020-11-28 20:58:54.792383] [0x0000000103cc7d40] [error]   3dx drivers module loading error: dlopen(/Library/Frameworks/3DconnexionClient.framework/3DconnexionClient, 5): image not found
zsh: segmentation fault  src/prusa-slicer

Process:               PrusaSlicer [38238]
Path:                  /Users/USER/Documents/*/prusa-slicer
Identifier:            PrusaSlicer
Version:               0
Code Type:             ARM-64 (Native)
Parent Process:        zsh [51002]
Responsible:           iTerm2 [31973]
User ID:               501

Date/Time:             2020-11-28 20:58:54.880 +0100
OS Version:            macOS 11.0.1 (20B29)
Report Version:        12

Time Awake Since Boot: 96000 seconds
Time Since Wake:       11000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  slic3r_main  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000006511930a8
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [38238]

obelisk commented 3 years ago

Still have issues building TBB on my M1, I have a patch but I don't think it's a good one.

Was able to replicate @xarbit's error as well.

I'm attempting to track down the error, it's weird that it doesn't show up in my build :/

obelisk commented 3 years ago

@xarbit I found the crashing issue and put it up in a draft here: https://github.com/prusa3d/PrusaSlicer/pull/5316

Pick it on to your brach if you'd like :)

xarbit commented 3 years ago

@obelisk very cool :-) I can confirm that it works with an updated wxWidgets and removing the override. But since Prusa3D uses a custom version of wxWidgets, I guess this will be addressed directly in that branch. We should create an issue there ...

xarbit commented 3 years ago

@obelisk @W3DRK mind testing this dirty packed app package? :-) It runs on my machine .. https://mega.nz/file/GfR03Tbb#kOf_3SfIvvnrzGxVnmbIqvrhsINuLqZj9W0_Tmo1od4

W3DRK commented 3 years ago

@obelisk @W3DRK mind testing this dirty packed app package? :-) It runs on my machine .. https://mega.nz/file/GfR03Tbb#kOf_3SfIvvnrzGxVnmbIqvrhsINuLqZj9W0_Tmo1od4

It works!

Edit: I should add that when comparing side by side when previewing complex sliced STLs, the native Apple Silicon build is noticeably smoother than the Intel binary.

Thanks to everyone putting effort into this!

xarbit commented 3 years ago

@W3DRK cool .. thanks for you're feedback .

bubnikv commented 3 years ago

I got my hands on an MacBook Air with M1 CPU and 8GB RAM today morning.

I have the brew installed. It was not quite a smooth ride, I had to pull a patched brew formula for python as a dependency for CMake. I pulled "Apple silicon support #5313" and I was able to compile dependencies and PrusaSlicer. PrusaSlicer crashes somewhere inside wxWidgets 3.1.3 as reported.

I am therefore trying now the patched wxWidgets 3.1.4, compilation is running. https://github.com/xarbit/wxWidgets/tree/v3.1.4-patched

Next is to patch: src/slic3r/GUI/GUI_App.hpp and remove the override keyword on line 256, and 257. This is wrong but I haven't had time to dig through the code and figure out what the right thing is.

That is because I have patched our wxWidgets 3.1.3 to make the two methods virtual, so we can override them to capture the file open callbacks from the OSX desktop before the parameters are processed by wxWidgets. I suppose this patch is not in https://github.com/xarbit/wxWidgets/tree/v3.1.4-patched yet.

Once the binary is running, I will try to put together the "universal" binary. I am quite worried about switching the wxWidgets from 3.1.3 to 3.1.4. We have experienced some major incompatibilities before. It is usually much safer for us to back port some minor bug fixes from 3.1.4 to 3.1.3. Indeed, some of the patches of our 3.1.3 wxWidgets fork are just back ports. On the other side there was around 1500 commits between 3.1.3 and 3.1.4 and the changes to support OSX 11 may have been substantial, so it is likely safer for now to try to compile PrusaSlicer 2.3 against wxWidgets 3.1.4 just on OSX 11/ARM. In that case I will have to review https://github.com/xarbit/wxWidgets/tree/v3.1.4-patched and fill in the missing pieces.

Thanks guys for all your hard work. It helped a lot indeed!

xarbit commented 3 years ago

@bubnikv thank you, that is great news :-) really looking forward ..

as a side note, the font patches did not work in v3.1.4-patched so I reverted them (as you will see in the commit log), also in the v3.1.4-patched branch the MacOpenFiles override works but currently not the OSXStoreOpenFiles.

OSXStoreOpenFiles works when the override is removed.

bubnikv commented 3 years ago

Compiled in 4m0.5s on that MacBook Air. That does not quite live up to the expectations given the hype, but not bad for such a portable unit. Unit tests are running without error after I updated the Catch2 framework.

obelisk commented 3 years ago

Curious as to what compilation times you guys had before? When I'm working on my Rust projects I've found it compiles in about half the time which was really nice to see but I had no reference point for PrusaSlicer.

Maybe one day we can introduce some Rust into PrusaSlicer :D

bubnikv commented 3 years ago

Yeah, I was quick in my judgement. I tried on Linux / WSL2 on my AMD Ryzen 9 3900X 12 core processor, 3793 MHZ clock. On that 12 core processor the compile time of the whole PrusaSlicer project (PrusaSlicer, some dependencies, test projects) took around 3 minutes, while on that "entry level" mac book it took 4 minutes. I have to say I don't like Apple's way of doing business, I don't like their desktop system and I hate their keyboards, but this time with their CPU/RAM SOC they did it, they are making history.

út 1. 12. 2020 v 17:38 odesílatel Mitchell Grenier notifications@github.com napsal:

Curious as to what compilation times you guys had before? When I'm working on my Rust projects I've found it compiles in about half the time which was really nice to see but I had no reference point for PrusaSlicer.

Maybe one day we can introduce some Rust into PrusaSlicer :D

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/5179#issuecomment-736669787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSIZLEKEBX3IJZFWQSD3SSULZHANCNFSM4TYSULLA .

bubnikv commented 3 years ago

Thanks guys for all your effort.

1) I have merged all the pull requests into PrusaSlicer 2) I have merged the wxWidgets v3.1.4-patched branch into our wxWidgets fork. I have also committed one more patch to add the "virtual" to one of those interfaces which we made virtual in v3.1.3-patched to override and for which PrusaSlicer was failing to compile. 3) I have updated PrusaSlicer build scripts to pull wxWidgets 3.1.4-patched from our repository just for the OSX ARM build.

Now PrusaSlicer dependencies and PrusaSlicer compile out of the box on OSX ARM.

I have also tested, that it is sufficient to call

lipo -create prusa-slicer-x86 prusa-slicer-arm -output PrusaSlicer

and that is about it to create the universal binary.

I will spend some time tomorrow reviewing all the patches that we did to wxWidgets 3.1.3 and I will try to bring them to 3.1.4. I know there were some font issues on Big Sur, and we have reports that the combo box at the bottom of the G-code viewer opens down outside the screen on Big Sur, so I shall try to fix that as well. Then I will pass this laptop to our tester to retest mainly against wxWidgets 3.1.4 induced surprises.

If everything works, we may produce further beta, rc and final builds as OSX universal binaries, however manually: We would have to compile on that laptop, then take the .dmg from our build server and either with a script or manually call that lipo tool, re-sign etc. We are a bit worried to touch the build server before the final release, thus this process will have to remain manual at least this year.

For the future, we need to update the dependency CMakes and the PrusaSlicer CMakes to cross-compile to ARM on our X86 based build server. That is quite a challenge. My understanding is, we need to pass a parameter -target arm64-apple-macos11 to all executions of a compiler or a linker. We would welcome patches, as it is extremely time consuming to do that for all the dependencies.

Thanks again for your help. We would be very thankful if you could also help us to pinpoint potential issues caused by migration to wxWidgets 3.1.4 or by migration to ARM.

bubnikv commented 3 years ago

By the way, our ARM based Macbook Air is now in hands of our tester @FidelCapo. He has found out, that both the ARM and the Intel builds of PrusaSlicer 2.3.0-beta2 (to be released today) render extremely slowly in G-code preview with large and / or complex models. That is a bad news. Do you experience such behavior? If so, hints and patches are most welcome :-) Otherwise I will likely get my hands on the machine around Wednesday to start poking around the rendering issues.

Also @FidelCapo tested the latest Cura according to him it is not usable at all on that ARM Mac.

xarbit commented 3 years ago

@bubnikv i will test tonight and report here.

mind sharing the stl used?

obelisk commented 3 years ago

@bubnikv I noticed this but I also experience really bad performance on the rosetta builds as well so I didn't think to mention it. I also have never used PrusaSlicer on macOS before (usually I use it on my Ryzen desktop) so I didn't have a base line. I tried to look in it but I wasn't sure where to start and then got distracted by other things.

@xarbit Try rendering the settlers of catan tiles at very fine detail: https://www.thingiverse.com/thing:1045223

obelisk commented 3 years ago

I also suggest we open a new issue for the M1 performance regression.

xarbit commented 3 years ago

@obelisk thanks, I tried a few .. set them to Ultra Detail. But, I personally did not feel anything that was wrong or extremely slowly, but that might just be me as I usually print mechanical things..

So this is what I plan to do tomorrow....

I will try a few tests again on my Intel based MacBook Pro from 2020, my Linux ThinkPad T480 and compare them with my ARM based MacBook Pro so I can get a feeling what "extremely slow" really means. Please keep me updated if we decide to use a new ticket for this.

@bubnikv

update: ok, I quickly try'd this https://www.thingiverse.com/thing:2014307/files (Waving_Groot_15.5cm.stl) It sure took awhile .. I will use that file as my reference tomorrow.

FidelCapo commented 3 years ago

Can you try this stl? Gcode preview was very slow (less then 1FPS) and GPU is at 100% after slicing on M1 MacBook Air. Adalinda.stl.zip

obelisk commented 3 years ago

Completely usable when layer height is > 0.10 mm. As soon as I sliced at 0.10, the entire program locked up and I had to force quit.

Here is a table of my findings:

Layer Height	CPU Usage	GPU Usage
0.25	100	85
0.20	110	90
0.15	110	95
0.10	Lock up on rotation	Lockup on rotation

I also looked at memory but didn't see anything out of the ordinary there (hovering around 1-2GB RMEM, 392 VMEM for all details). The usage of CPU and GPU seem to be pretty consistent up until it completely locks up so I feel it could be unrelated but that's obviously a tough sell.

On another note, if you have the slicing level down (so you're only viewing part of the slice) it renders much, much faster. I haven't looked through the rendering code (I uhhh, don't know how :p) but I imagine something about the sheer number of objects being rotated in 3D space is causing the issues (whether that's layers or individual tool moves).

xarbit commented 3 years ago

@FidelCapo, @bubnikv on my MacBook Pro M1 it works pretty well on 0.3mm layer height :-) .. at 0.2 layer height it starts to get sluggish and everything with higher resolution over 0.2 is very bad and makes the the application just hang and PrusaSlicer 2.3 gets unresponsive.

I also tested this model on PrusaSlicer 2.3 Beta 2 on my Intel based MacBook Pro 2020 .. it is better, yes ..but there are noticeable performance regression there too .. Compared to PrusaSlicer 2.2 on my M1 Mac running over Rosetta2 or bare Intel based .. 2.3 beta is slow on Mac ..

obelisk commented 3 years ago

Confirmed @xarbit's findings as well, 2.2.0 through rosetta has no issues going all the way down to 0.05mm

bubnikv commented 3 years ago

@xarbit @obelisk thanks, we have a problem here.

obelisk commented 3 years ago

@bubnikv I have the bad revision (I think). I'm trying to figure out if something broke rendering speed but before that commit, it works, after. It's horribly slow, and at some point after that it starts hanging entirely. So I think there might be two issues.

prusa3d / PrusaSlicer

[AppleSilicon] Building PrusaSlicer on new Apple ARM based Mac's #5179

5305 https://github.com/prusa3d/PrusaSlicer/pull/5305