Howdy all,
Apple announced today that it will transition from Intel to its own Arm processors. What this will bring is:
* Universal 2: x86_64 & arm fat binaries * Rosetta 2: emulation layer from x86_64 to arm
For Pd, this means that current binaries will most likely *run* but who knows how the performance will be good for realtime DSP. OTOH, they did demo a game and some virtualization support so it seems they have focused on making things run as well as they can.
Building Pd itself for macOS arm should be relatively easy, just a different arch target. For externals, this would may require an additional fat lib type, perhaps dfat_2? Note, I believe the distinction will be important for us since we still have "Universal 1" builds. As with the Pd core, updating pd-lib-builder should also be relatively easy by adding the new arch targets, depending on what they are.
For deken, this means recompiling and uploading the new fat type.
I don't imagine it will be possible to have a "fatter lib" which supports ppc, x86, x86_64, & arm. I believe the writing is on the wall for the eventual need for a build system newer then OS X 10.6.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Hi Dan and others -
The "fat" binary format itself might not have to be changed to allow another architecture to be added, but knowing Apple they might well change the file format anyhow just to force some more upgrades. But regardless it will be necessary to recompile all externs (and Pd itself) to add the arm arcitecture. I doubt I'll be able to do that on my old Mac. It might be time I investigated whether cross-compiling from linux is at all feasible.
cheers Miller
On Mon, Jun 22, 2020 at 11:24:04PM +0200, Dan Wilcox wrote:
Howdy all,
Apple announced today that it will transition from Intel to its own Arm processors. What this will bring is:
- Universal 2: x86_64 & arm fat binaries
- Rosetta 2: emulation layer from x86_64 to arm
For Pd, this means that current binaries will most likely *run* but who knows how the performance will be good for realtime DSP. OTOH, they did demo a game and some virtualization support so it seems they have focused on making things run as well as they can.
Building Pd itself for macOS arm should be relatively easy, just a different arch target. For externals, this would may require an additional fat lib type, perhaps dfat_2? Note, I believe the distinction will be important for us since we still have "Universal 1" builds. As with the Pd core, updating pd-lib-builder should also be relatively easy by adding the new arch targets, depending on what they are.
For deken, this means recompiling and uploading the new fat type.
I don't imagine it will be possible to have a "fatter lib" which supports ppc, x86, x86_64, & arm. I believe the writing is on the wall for the eventual need for a build system newer then OS X 10.6.
Dan Wilcox @danomatika <https://urldefense.com/v3/__http://twitter.com/danomatika__;!!Mih3wA!V8X7Spm... > danomatika.com <https://urldefense.com/v3/__http://danomatika.com/__;!!Mih3wA!V8X7SpmssWAD6e... > robotcowboy.com <https://urldefense.com/v3/__http://robotcowboy.com/__;!!Mih3wA!V8X7SpmssWAD6... >
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
but knowing Apple they might well change the file format anyhow just to force some more upgrades
Yes, from what I understood from the articles I've read, they want to create a new file format for fat x86_64 / arm binaries.
What I don't understand is: the FAT format already supports all kinds of binaries, including ARM64 (CPU_TYPE_ARM64). Also, I don't see why apple shouldn't be able to keep supporting existing x86_64 binaries (FAT or mach-O) on their ARM machines...
But I'm sure they have technically convincing reasons for this :-p. But let's see.
Christof
On 23.06.2020 05:43, Miller Puckette via Pd-dev wrote
Hi Dan and others -
The "fat" binary format itself might not have to be changed to allow another architecture to be added, but knowing Apple they might well change the file format anyhow just to force some more upgrades. But regardless it will be necessary to recompile all externs (and Pd itself) to add the arm arcitecture. I doubt I'll be able to do that on my old Mac. It might be time I investigated whether cross-compiling from linux is at all feasible.
cheers Miller
On Mon, Jun 22, 2020 at 11:24:04PM +0200, Dan Wilcox wrote:
Howdy all,
Apple announced today that it will transition from Intel to its own Arm processors. What this will bring is:
- Universal 2: x86_64 & arm fat binaries
- Rosetta 2: emulation layer from x86_64 to arm
For Pd, this means that current binaries will most likely *run* but who knows how the performance will be good for realtime DSP. OTOH, they did demo a game and some virtualization support so it seems they have focused on making things run as well as they can.
Building Pd itself for macOS arm should be relatively easy, just a different arch target. For externals, this would may require an additional fat lib type, perhaps dfat_2? Note, I believe the distinction will be important for us since we still have "Universal 1" builds. As with the Pd core, updating pd-lib-builder should also be relatively easy by adding the new arch targets, depending on what they are.
For deken, this means recompiling and uploading the new fat type.
I don't imagine it will be possible to have a "fatter lib" which supports ppc, x86, x86_64, & arm. I believe the writing is on the wall for the eventual need for a build system newer then OS X 10.6.
Dan Wilcox @danomatika <https://urldefense.com/v3/__http://twitter.com/danomatika__;!!Mih3wA!V8X7Spm... > danomatika.com <https://urldefense.com/v3/__http://danomatika.com/__;!!Mih3wA!V8X7SpmssWAD6e... > robotcowboy.com <https://urldefense.com/v3/__http://robotcowboy.com/__;!!Mih3wA!V8X7SpmssWAD6... >
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Tue, Jun 23, 2020 at 5:21 AM Christof Ressi info@christofressi.com wrote:
but knowing Apple they might well change the file format anyhow just to force some more upgrades
Yes, from what I understood from the articles I've read, they want to create a new file format for fat x86_64 / arm binaries.
What I don't understand is: the FAT format already supports all kinds of binaries, including ARM64 (CPU_TYPE_ARM64). Also, I don't see why apple shouldn't be able to keep supporting existing x86_64 binaries (FAT or mach-O) on their ARM machines...
But I'm sure they have technically convincing reasons for this :-p. But let's see.
It's known as 'planned obsolescence'. It allows a monopoly to charge 'technological rent' above and beyond any added value from the manufacturing princess.
Martin
It looks like the fat format basically stays the same with the addition of the new architecture. Someone has already succeeded in making a Arm+Intel+PPC fat binary:
https://www.macrumors.com/2020/07/11/arm-intel-powerpc-universal/ https://www.macrumors.com/2020/07/11/arm-intel-powerpc-universal/
On Jun 23, 2020, at 5:43 AM, Miller Puckette msp@ucsd.edu wrote:
Hi Dan and others -
The "fat" binary format itself might not have to be changed to allow another architecture to be added, but knowing Apple they might well change the file format anyhow just to force some more upgrades. But regardless it will be necessary to recompile all externs (and Pd itself) to add the arm arcitecture. I doubt I'll be able to do that on my old Mac. It might be time I investigated whether cross-compiling from linux is at all feasible.
cheers Miller
On Mon, Jun 22, 2020 at 11:24:04PM +0200, Dan Wilcox wrote:
Howdy all,
Apple announced today that it will transition from Intel to its own Arm processors. What this will bring is:
- Universal 2: x86_64 & arm fat binaries
- Rosetta 2: emulation layer from x86_64 to arm
For Pd, this means that current binaries will most likely *run* but who knows how the performance will be good for realtime DSP. OTOH, they did demo a game and some virtualization support so it seems they have focused on making things run as well as they can.
Building Pd itself for macOS arm should be relatively easy, just a different arch target. For externals, this would may require an additional fat lib type, perhaps dfat_2? Note, I believe the distinction will be important for us since we still have "Universal 1" builds. As with the Pd core, updating pd-lib-builder should also be relatively easy by adding the new arch targets, depending on what they are.
For deken, this means recompiling and uploading the new fat type.
I don't imagine it will be possible to have a "fatter lib" which supports ppc, x86, x86_64, & arm. I believe the writing is on the wall for the eventual need for a build system newer then OS X 10.6.
Dan Wilcox @danomatika <https://urldefense.com/v3/__http://twitter.com/danomatika__;!!Mih3wA!V8X7Spm... https://urldefense.com/v3/__http://twitter.com/danomatika__;!!Mih3wA!V8X7SpmssWAD6eANe3F_3fQH7pHBkQ_8gyeJSAE6yMjWL2dFHe-3_ZpPEFz4$ > danomatika.com http://danomatika.com/<https://urldefense.com/v3/__http://danomatika.com/__;!!Mih3wA!V8X7SpmssWAD6e... https://urldefense.com/v3/__http://danomatika.com/__;!!Mih3wA!V8X7SpmssWAD6eANe3F_3fQH7pHBkQ_8gyeJSAE6yMjWL2dFHe-3_Q6Jispv$ > robotcowboy.com http://robotcowboy.com/<https://urldefense.com/v3/__http://robotcowboy.com/__;!!Mih3wA!V8X7SpmssWAD6... https://urldefense.com/v3/__http://robotcowboy.com/__;!!Mih3wA!V8X7SpmssWAD6eANe3F_3fQH7pHBkQ_8gyeJSAE6yMjWL2dFHe-3_YuGSoHi$ >
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!... https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!V8X7SpmssWAD6eANe3F_3fQH7pHBkQ_8gyeJSAE6yMjWL2dFHe-3_Z11NUwg$
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Am 22. Juni 2020 23:24:04 MESZ schrieb Dan Wilcox danomatika@gmail.com:
Howdy all,
Apple announced today that it will transition from Intel to its own Arm processors.
oh. i thought they made that switch in 2007.
What this will bring is:
- Universal 2: x86_64 & arm fat binaries
Building Pd itself for macOS arm should be relatively easy, just a different arch target. For externals, this would may require an additional fat lib type, perhaps dfat_2? Note, I believe the distinction will be important for us since we still have "Universal 1" builds.
hmm. why? the original d_fat externals for Pd won't run on modern mac(hine)s at all, as they contained ppc and i386, which are both unsupported these days. yet the file format ( the container) stays the same, and it is totally possible to have a d_fat that runs on ppc, ppc64 (an arch that was never officially supported by PD), i386 and x86_64, so running on all architectures ever supported by OSX (modulo system libraries...). why not just add arm64 to that list?
so initially, I was going to rebuke the idea oft a d_fat2 format.
apple's labelling as "Universal 2" is a bit concerning though...
anyhow, I don't really see why apple should make a 2nd universal format. iirc, "fat" is a technology from NextStep, so its well aged, and has proven itself. this of course is no reason to not drop it.
more important: can you (well: they) make money with a new format? i'm having a hard time here to imagine how (but then: i'm not very good in imagining how to make money in general).
i don't think there are still enough ppc users left for apple to care about them. thinkgs might be different with i386 though.
however, i guess the biggest issue is for the developers it's getting really hard to create fat binaries that cover more architectures than x86_64 and i-arm64. that's because there's no reasonable toolchains available that allow you to do so. to build binaries for the new arm architecture, you probably need XCode12, which - like XCode10 and XCode11 - won't support x86_64 (and PPC has been dropped around XCode4, if my wikipedia foo is correct). so the only way to produce fat binaries (that include mor ethan x86_&4 and amd64) is to have multiple build systems (parts of them unsupported by now) and combine the artifacts into a single binary in a second step.
that sounds like a big enough hurdle to be a rather plump nudge for most applications to support only "recent" architecture. no need to invent a new format.
fgmasd IOhannes
What do you think this will do for the GPU support though? There are a couple mali architectures now that support OpenGL ( Bifrost https://wiki.debian.org/PanfrostLima )
I'm out of practice, but I was once tinkering with an Allwinner A80 with a PowerVR GPU, and there was OpenGL support in the proprietary binaries, somewhere.... I gave up. It does Open GLES and sits in a drawer until I think of what to do with it
or do you think they'll adopt NVIDIA (like the jetson nano)? NV already puts pci-e (some lanes) on its jetsons with arm cores, so in a few more cycles, maybe there will be enough on-chip to support all the connectors, network stuff that apple puts on laptops/desktops
And there was that fusion CL/GL API they wanted to put out called Metal. I haven't followed along with its progress. Is it related?
Chuck
On Mon, Jun 22, 2020 at 4:25 PM Dan Wilcox danomatika@gmail.com wrote:
Howdy all,
Apple announced today that it will transition from Intel to its own Arm processors. What this will bring is:
- Universal 2: x86_64 & arm fat binaries
- Rosetta 2: emulation layer from x86_64 to arm
For Pd, this means that current binaries will most likely *run* but who knows how the performance will be good for realtime DSP. OTOH, they did demo a game and some virtualization support so it seems they have focused on making things run as well as they can.
Building Pd itself for macOS arm should be relatively easy, just a different arch target. For externals, this would may require an additional fat lib type, perhaps dfat_2? Note, I believe the distinction will be important for us since we still have "Universal 1" builds. As with the Pd core, updating pd-lib-builder should also be relatively easy by adding the new arch targets, depending on what they are.
For deken, this means recompiling and uploading the new fat type.
I don't imagine it will be possible to have a "fatter lib" which supports ppc, x86, x86_64, & arm. I believe the writing is on the wall for the eventual need for a build system newer then OS X 10.6.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I'll answer my own questions (I think)
On Fri, Jun 26, 2020 at 11:40 AM Charles Z Henry czhenry@gmail.com wrote:
What do you think this will do for the GPU support though?
The last time Apple used a PowerVR GPU was on the A10 in 2016. Since then, Apple has been designing their own "4-core", "6-core", and "8-core" GPUs on their A-series chips.
There are a couple mali architectures now that support OpenGL ( Bifrost https://wiki.debian.org/PanfrostLima )
So, probably not going down this path.
I'm out of practice, but I was once tinkering with an Allwinner A80 with a PowerVR GPU, and there was OpenGL support in the proprietary binaries, somewhere.... I gave up. It does Open GLES and sits in a drawer until I think of what to do with it
Jan 2020, and it's still a headline to get linux running on an A10: https://tuxphones.com/linux-kernel-boots-on-t8010-a10-iphone-7-via-pongoos/
or do you think they'll adopt NVIDIA (like the jetson nano)? NV already puts pci-e (some lanes) on its jetsons with arm cores, so in a few more cycles, maybe there will be enough on-chip to support all the connectors, network stuff that apple puts on laptops/desktops
Probably not this either.
And there was that fusion CL/GL API they wanted to put out called Metal. I haven't followed along with its progress. Is it related?
Seems like a lot of work to keep all those custom GPU's supported. I guess, No.
On Mon, Jun 22, 2020 at 4:25 PM Dan Wilcox danomatika@gmail.com wrote:
Howdy all,
Apple announced today that it will transition from Intel to its own Arm processors. What this will bring is:
- Universal 2: x86_64 & arm fat binaries
- Rosetta 2: emulation layer from x86_64 to arm
For Pd, this means that current binaries will most likely *run* but who knows how the performance will be good for realtime DSP. OTOH, they did demo a game and some virtualization support so it seems they have focused on making things run as well as they can.
Building Pd itself for macOS arm should be relatively easy, just a different arch target. For externals, this would may require an additional fat lib type, perhaps dfat_2? Note, I believe the distinction will be important for us since we still have "Universal 1" builds. As with the Pd core, updating pd-lib-builder should also be relatively easy by adding the new arch targets, depending on what they are.
For deken, this means recompiling and uploading the new fat type.
I don't imagine it will be possible to have a "fatter lib" which supports ppc, x86, x86_64, & arm. I believe the writing is on the wall for the eventual need for a build system newer then OS X 10.6.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Charles Z Henry -
Christof Ressi -
Dan Wilcox -
IOhannes m zmölnig -
Martin Peach -
Miller Puckette