First see if we can compile stuff locally. That last part can be a challenge because now we don't need to pay since we're an open-source project. This work will atleast gives is an indication if it can all be build on M1, from there my work start by setting up the virtual runners, either cross-compiling or Arm based and integrating that in our workflow and ensure that we have funding for building on those special runners. I think the conan part is covered already, so all our C++ deps should be able to be build. Add them to requirements, maybe Bump-up a version or two. If that works, then you just have to figure out the hashes for the M1 wheels. How I would personally handles this, is to first remove all hashes and version numbers of the Python requirements in the requirements.txt in both repo and see if you can get away with creating a Python virtual were you install all these requirements with pip. I think you could get away with 1 PR (per repo) keep in mind that Uranium also has Python requirements. Rest assured, we're planning on supporting the M1 natively but it will cost us money, time and effort and that means that we need to prioritize it compared to our other tickets on the backlog. An educated guess is that you would need to compile Numpy, SciPy and various other Python modules which rely on binary bindings of C/C++ code to make it work on the M1 Such an investigation/spike could be done by following the instruction on our wiki in a native M1 terminal environment. Seeing that you guys are so eager to have native M1 support I hope I can enlist your help to figure out which other dependencies need to be upgraded/changed, apart from Qt and PyQt, to build a native M1 Cura. The plus side of this whole migration effort is that it is now much easier to build and run Cura from source. Please refrain from making such assumptions. So to be honest I take a little bit offense to the suggestion that we're lazy. This migration cost me 6 months of my working live and added 10 years to my receding hair line. Migrating our whole build process to GitHub runners and using Conan to manage our build artifacts. Apart from laying the groundwork to even facilitate such a thing. Please remember that switching architecture is not a trivial thing to do, it also requires a significant investment in hardware and subscribed services from UltiMaker side. Which is only supported (via Rosetta) since Qt6 6.2. We have a ticket on our backlog for this CURA-9565 so it is on our radar and we have been working on this for a while, basically our whole upgrade to Qt6 was needed to facilitate the M1. :( that said, as always- thanks for all you do, i know that OSS is not the easiest thing to keep on top of :) I get y'all might not have a lot of time to get into it, but it looks like the last time one of the repo collaborators commented was april - when in reality all that most of us ever want is communication, that could be seen as a bit extreme. I myself have converted several projects to work natively on m1 / p圓. I'd say that many if not most libraries are apple silicon friendly at this point, and configuring the build process really shouldn't be that difficult. You're based on pyQt, right? seems like Qt 6 is already to go on apple silicon, including dual build support. I on the other hand would say it is pretty out there to assume something like this is fairly straightforward to fix without any knowledge about the frameworks that are being used and the effort involved in getting those to work on an entirely different processor architecture. Some developers even made their app ready from Day One when the first M1 Mac came to market! Hey, macOS betas and the Apple Silicon Developer Transition Kit were made for that after all. Rosetta 2 was a temporary solution provided in 2020 with MacOS Big Sur to let developers the time to update their code base to Universal apps, which the industry has done in its vast majority since then. So that an ancient app made for Intel works on an Apple Silicon Mac.Īlthough the Rosetta 2 transcoding process is well done (very optimized) it comes with drawbacks, that are some additional slowness, a few bugs and incompatibilities, and a high RAM usage when compared to a native (Universal) app. It seamlessly (transparently) transcodes the old x86_64 code of old non-native apps made for Intel CPUs, into the newer ARM64 instruction set used in their recent M1 & M2 CPUs. What would be the point of downloading the Windows PC version of Cura then run it on a Mac through a virtualization software like Parallels Desktop or VMware Fusion? Madness! On latest Mac computers, Apple provides Rosetta 2 in macOS. What are you talking about? Ultimaker makes a version of Cura for Mac already. Arm64 version will work natively (without using parallels or something like it) in M1 chip?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |