Apple M1 migtation
Hi all,
If you haven‘t heard already, Apple are moving to their own ARM based
hardware architecture.
My question is, how deep does the Python behind the OpenSCAD app go? Is it
running entirely in Python, or are their platform dependent compiletime
components?
I’m asking this because, if it’s entirely Python3, the transition to the new
Apple M1 hardware may just inherently be done. If there are native
compiletime components it may still cope by using Rosetta 2, the built in
emulator. I will be receiving a Macbook Air M1 before Christmas, so happy to
be a beta tester for this. I know I should have probably bought sooner, lol,
but had other affairs to settle first beforeI knew what I could afford.
Suggesting I use other platforms will be ignored. I’m genuinely willing to
help this community to transition the Apple flavoured version (not a
programmer’s bung, but understand enough to follow basic compile
instructions) and provide feedback on nightly builds.
My apologies if this is a newb question but it’s time for to give back what
I to the real programmers here because I love this app and have a genuine
need for it.
Make things, travel and tell stories.
Sent from: http://forum.openscad.org/
I would be shocked if the app didn't launch, or if things like STL
generation didn't work. This is the kind of job that Apple Silicon
generally does better than much higher-end Intel machines, even in
emulation. CGAL is CPU-based, so it shouldn't be a problem. Being
single-threaded means that it will benefit from the increased single-core
performance, but not from the increased core count.
What I'm worried about is issues with OpenCSG on the new Apple GPUs. These
types of unusual graphical functions are the types of things that can have
show-stopping bugs, based on the reviews and info that I've seen.
On November 25, 2020 at 12:02:16, crunchysteve (bandmassa@gmail.com) wrote:
Hi all,
If you haven‘t heard already, Apple are moving to their own ARM based
hardware architecture.
My question is, how deep does the Python behind the OpenSCAD app go? Is it
running entirely in Python, or are their platform dependent compiletime
components?
I’m asking this because, if it’s entirely Python3, the transition to the new
Apple M1 hardware may just inherently be done. If there are native
compiletime components it may still cope by using Rosetta 2, the built in
emulator. I will be receiving a Macbook Air M1 before Christmas, so happy to
be a beta tester for this. I know I should have probably bought sooner, lol,
but had other affairs to settle first beforeI knew what I could afford.
Suggesting I use other platforms will be ignored. I’m genuinely willing to
help this community to transition the Apple flavoured version (not a
programmer’s bung, but understand enough to follow basic compile
instructions) and provide feedback on nightly builds.
My apologies if this is a newb question but it’s time for to give back what
I to the real programmers here because I love this app and have a genuine
need for it.
Make things, travel and tell stories.
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 25.11.20 21:01, crunchysteve wrote:
My question is, how deep does the Python behind the
OpenSCAD app go?
There is no python in the normal application installation.
It's only used at build time, e.g. to run the test suite.
It might run via Rosetta 2, that will have to be seen when
someone can actually try this. So if you get the M1 Air,
it would be interesting to hear if and how it works.
Suggesting I use other platforms will be ignored. I’m
genuinely willing to help this community to transition
the Apple flavoured version (not a programmer’s bung,
but understand enough to follow basic compile instructions)
and provide feedback on nightly builds.
That kind of help would go a long way. Right now I don't
have contact to someone who both has an Apple machine to
build on and also the time to help. I can barely run
pre-built binaries on the old 2009 MacBook Pro machine
I have sitting here.
ciao,
Torsten.
Rverything I find on the subject that I confidently understand gives me hope
that the transition should be a smooth one, but it’s the deep backend bits,
like CGAL that have me worries. However, I have my old Air to fall back on,
so trying out nightly builds on the new one is something I can and will do.
I’m looking forward to the fun 😁
Make things, travel and tell stories.
Sent from: http://forum.openscad.org/
I'm still fighting with building openScad for aarch64 on Linux (mainly
because of AppImage). I don't know how this will go on the M1 (which also
is aarch64 if I'm not mistaken).
I know the whole ecosystem is different.
On Wed, Nov 25, 2020, 21:21 crunchysteve bandmassa@gmail.com wrote:
Rverything I find on the subject that I confidently understand gives me
hope
that the transition should be a smooth one, but it’s the deep backend bits,
like CGAL that have me worries. However, I have my old Air to fall back on,
so trying out nightly builds on the new one is something I can and will do.
I’m looking forward to the fun 😁
Make things, travel and tell stories.
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 25.11.20 21:25, Verachten Bruno wrote:
I'm still fighting with building openScad for aarch64 on
Linux (mainly because of AppImage).
Why, what's the issue? There's a not fully up-to-date aarch64
AppImage built for RaspberryPI 64-bit and it builds fine on
Ubuntu 20.10 and Debian. So aarch64 in itself should not be
a problem
The question is probably more regarding the tools provided
(basically XCode at version >= 12.2 as far as I have read)
and the time needed to build.
ciao,
Torsten.
Again, CGAL is just CPU computation, which should be fast and easy, even in
emulation. I'd be much more worried about OpenCSG, which is GPU-based and
uses a bunch of really non-standard Z-buffer tricks, and has a history of
working inconsistently and requiring workarounds on different GPUs. It also
relies much more heavily on OpenGL, which is deprecated (though still
supported for the time being) in favor of the Metal framework.
On November 25, 2020 at 12:21:47, crunchysteve (bandmassa@gmail.com) wrote:
Rverything I find on the subject that I confidently understand gives me hope
that the transition should be a smooth one, but it’s the deep backend bits,
like CGAL that have me worries. However, I have my old Air to fall back on,
so trying out nightly builds on the new one is something I can and will do.
I’m looking forward to the fun 😁
Make things, travel and tell stories.
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 25.11.20 21:25, Verachten Bruno wrote:
I'm still fighting with building openScad for aarch64 on
Linux (mainly because of AppImage).
Why, what's the issue?
I'm having problems with cgal (installed but not found). Later on, I
also have problems with AppImage (no official aarch64 release), which
depends on LinuxDeploy (no official aarch64 release), which depends on
CMake (no official aarch64 release).
There's a not fully up-to-date aarch64
AppImage built for RaspberryPI 64-bit and it builds fine on
Ubuntu 20.10 and Debian. So aarch64 in itself should not be
a problem
Interesting. Would you please share a link, so that I can have a look
at how it is built? I would love to have code from master branch
compile regularly for aarch64.
Thanks a lot,
Bruno Verachten
On Wed, Nov 25, 2020 at 3:16 PM Torsten Paul Torsten.Paul@gmx.de wrote:
I can barely run
pre-built binaries on the old 2009 MacBook Pro machine
I have sitting here.
I'm in the same boat. My MBP is mid-2010. It runs fine, but it's
stuck in time. I will likely have to retire it in the next couple of
years.
I do not buy new Apple hardware. It's too expensive for me.
-ethan
On 26.11.20 09:28, Verachten Bruno wrote:
I'm having problems with cgal (installed but not found).
I've built based on a Debian Docker image, so that worked
with the normal cgal package.
Base Image:
https://github.com/openscad/docker-openscad/tree/master/appimage/appimage-arm64v8-base
OpenSCAD Build:
https://github.com/openscad/docker-openscad/tree/master/appimage/appimage-arm64v8-openscad
Interesting. Would you please share a link, so that I can have a
look at how it is built? I would love to have code from master
branch compile regularly for aarch64.
That is the one built via Docker linked above. Link is on the
normal download page / snapshot section:
https://www.openscad.org/downloads.html#snapshots
ciao,
Torsten.