Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Waragainstsleep

macrumors 6502a
Oct 15, 2003
612
221
UK
China Times has reported that Apple is working on a GPU codenamed "Lifuka" which will be built on TSMC's 5nm process and believed to first see use in the ASi iMac in 2021.

Interesting, hadn't heard that one.


When you look at the hardware, the numbers sound more reasonable (don't quote me on that, I might have made some mistakes here)

Nvidia RTX 3080: a 68-core parallel processor cluster (each processor having four 512-bit SIMD ALUs)
AMD 5700XT: a 40-core parallel processor cluster (each processor having two 1024-bit SIMD ALUs)
Apple A12Z: a 8 core parallel processor cluster (each processor having probably two 1024-bit SIMD ALUs, not 100% sure)

From these numbers it looks like the job Apple has to do with its GPUs is in the same ball park as the job it has to do for its CPUs. Scaling from 4/8 cores to ~32/64 or so. If they really have lined up a 5nm GPU card for 2021 they must have samples running in their labs already.

Its been rather fascinating to speculate about what they are up to. I hope they announce an AS Mac next week. On the one hand they typically prefer to keep iPhone events for iPhones I think but surely they aren't going to hold a 3rd event so close to the other two? And surely they are trying to get them out for Christmas, so it can't be long now.
 

Gerdi

macrumors 6502
Apr 25, 2020
449
301
Few words regarding x86 emulation in Windows ARM. It is regarded as one of the fastest implementation of a x86->ARM64 JIT engine. If you are running Geekbench or other benchmarks the performance hit compared to native is about 50%. And yes, the emulation is x86->Aarch64 (and not Aarch32).

Speaking of games, which can easily be GPU limited running fine under CPU emulation provided you have a Direct3d driver. Of course you cannot expect to get desktop performance out of a low power device - but emulation typically is not the biggest limiting factor.

To get an idea, see the link below:
x86 games running under emulation on the Surface Pro X

I believe having a proper Direct3d driver which maps to Metal on the host is one of the bigger hurdles for Windows games under AS Macs.
 

leman

macrumors Core
Oct 14, 2008
19,517
19,664
From these numbers it looks like the job Apple has to do with its GPUs is in the same ball park as the job it has to do for its CPUs. Scaling from 4/8 cores to ~32/64 or so. If they really have lined up a 5nm GPU card for 2021 they must have samples running in their labs already.

Its been rather fascinating to speculate about what they are up to. I hope they announce an AS Mac next week. On the one hand they typically prefer to keep iPhone events for iPhones I think but surely they aren't going to hold a 3rd event so close to the other two? And surely they are trying to get them out for Christmas, so it can't be long now.

There is no doubt that they will have more GPU cores on faster Macs. Fortunately, increasing the number of cores on a GPU is relatively simple and it scales well.

My speculation is that Apple will increase both the GPU cluster size and the width of SIMD ALUs per core. I actually believe the later is already done with A14 - it’s compute scores have doubled compared to A13. I wrote some baseless speculation here in case you are interested.
 

leman

macrumors Core
Oct 14, 2008
19,517
19,664
Few words regarding x86 emulation in Windows ARM. It is regarded as one of the fastest implementation of a x86->ARM64 JIT engine. If you are running Geekbench or other benchmarks the performance hit compared to native is about 50%. And yes, the emulation is x86->Aarch64 (and not Aarch32).

Do you happen to have a link where one can read more? Didn’t find much on MS website...


I believe having a proper Direct3d driver which maps to Metal on the host is one of the bigger hurdles for Windows games under AS Macs.

Parallels already have one.
 

leman

macrumors Core
Oct 14, 2008
19,517
19,664
Looking at all that ARM transition from the aspect of a average consumer who doesn't need or have a seperate work (laptop) / play (console).

Is it difficult/time consuming/expensive for Devs to create a basic video/music player, photo viewer/light editor (think iOS Photos or Microsoft Photo) that runs on ARM?

Also, what about the different web browsers (Chrome, Firefox, Safari and Edge) and their extensions?
is i(Pad)OS/MacOS Safari already compatible?

Let me just put it like this — if a dev already has an app that works for current macOS, they can most of the time fairly trivially make an ARM version out of it. Developing for ARM is just as difficult or easy as developing for Intel.

All Apple-provided Mac application already run on ARM macOS. Office, Photoshop etc. are said to have a working ARM version for Mac as well.

If you are using your laptop as a home/office computer and you don't really on any exotic software, it should be relatively "safe" for you to move to a new Apple Silicon Mac once it's released. If your work relies on running Windows in some fort or fashion (for Windows-specific software or games), I would hold off to see how things develop first.
 
  • Like
Reactions: MiniApple

eulslix

macrumors 6502
Dec 4, 2016
464
594
Let me just put it like this — if a dev already has an app that works for current macOS, they can most of the time fairly trivially make an ARM version out of it. Developing for ARM is just as difficult or easy as developing for Intel.

All Apple-provided Mac application already run on ARM macOS. Office, Photoshop etc. are said to have a working ARM version for Mac as well.

If you are using your laptop as a home/office computer and you don't really on any exotic software, it should be relatively "safe" for you to move to a new Apple Silicon Mac once it's released. If your work relies on running Windows in some fort or fashion (for Windows-specific software or games), I would hold off to see how things develop first.

I'd say in general, the bigger the studio, the more likely there is some form of legacy code which is a pain in the ass to port to another platform. At the same time, the bigger the studio, the less likely they can afford to pass on all MacOS users (unless its some B2B product where most clients have homegenous software environments).

But, of course, exceptions always apply. I have a really great deprecated tool from a book author which only runs on flash, so I currently use a contained standalone flash player to run it. I really don't have time to reimplement it myself. Since I don't expect Adobe to port their player onto ARM after deceasing support for it, this is pretty much a dead end. For this kind of cases I always have an old MBP lying around. And I kind of expect for most of us mortals it'll mostly be such old supporting tools which won't run anymore, but fortunately those should always run on older machines as well.

Worst case, just by some cheap used Microsoft Surface and be done with it. Still sucks to lug it around, but so does carrying the oversized overweight MBP 16, which I switched to purely because of Apples botched up keyboard.
 
  • Like
Reactions: MiniApple

leman

macrumors Core
Oct 14, 2008
19,517
19,664
I'd say in general, the bigger the studio, the more likely there is some form of legacy code which is a pain in the ass to port to another platform. At the same time, the bigger the studio, the less likely they can afford to pass on all MacOS users (unless its some B2B product where most clients have homegenous software environments).

ARM has designed Aarch64 to be as close to x86-64 in terms of basic behavior (data sizes and alignment), which makes porting much much easier, and Apple has been tightening the code compatibility constraints on macOS for years in preparation for this transition.

Complex legacy code is always a problem of course, but there are good solutions out there. Hand-written vector code can be trivially ported over by using a library like SIMD everywhere
Probably the biggest issue is porting highly complex hand-optimized multi-threading-aware code, since memory ordering guarantees are different between x86 and ARM... but how many vendors actually do something like that? Most will use a standard well-tested high-quality library for these things anyway.

I am not trying to say that all will be trivial, but I think that the porting challenge is probably generally overestimated. If a single person could make Photoshop — the prototypical legacy software — run on ARM Mac in under a week... how hard can the rest be?
 
  • Like
Reactions: eulslix

MiniApple

macrumors 6502
Sep 3, 2020
361
461
Many thanks @leman and @eulslix.
I'll be able to jump on the ARM bandwagon ASAP they release a product I like then.
My personal needs are covered and business/gaming is on separate devices anyway.
 

Gerdi

macrumors 6502
Apr 25, 2020
449
301
Do you happen to have a link where one can read more? Didn’t find much on MS website...

Not sure what you want to know. Just ask questions, which i probably can answer if it is Windows ARM related.
 
  • Like
Reactions: leman

leman

macrumors Core
Oct 14, 2008
19,517
19,664
Not sure what you want to know. Just ask questions, which i probably can answer if it is Windows ARM related.

Since you are making this nice offer, here are some questions :)

- To reiterate, you are saying that Windows on ARM JIT transpiler is leveraging Aarch64 to execute both x86-32 and x86-64 code?

- What x86 SIMD instruction sets are supported by the ARM transpiler?

- Future high-performance ARM CPUs are dropping Aarch32 alltogether. Is Windows on ARM ready for this? Does it currently have the ability to boot and run on an Aarch64-only ARM CPU? What are the limitations? How many apps for ARM Windows require Aarch32 to work?

Thanks in advance! I will totally understand if you can't answer all of these in detail, any kind of information would be appreciated.
 
  • Like
Reactions: jdb8167

Waragainstsleep

macrumors 6502a
Oct 15, 2003
612
221
UK
But, of course, exceptions always apply. I have a really great deprecated tool from a book author which only runs on flash, so I currently use a contained standalone flash player to run it. I really don't have time to reimplement it myself.

Couldn't you run that in a High Sierra VM or something like?
 

Gerdi

macrumors 6502
Apr 25, 2020
449
301
Just to get this straight, i do not work for Microsoft - so i do not have any insights into future projects like x86-64 support.

To reiterate, you are saying that Windows on ARM JIT transpiler is leveraging Aarch64 to execute both x86-32 and x86-64 code?

JIT is generating Aarch64 code. You can see this when connecting a debugger to an x86 process on an ARM device. Also all CHPE Dlls containing ARM64 code.
It is also save to assume that x86-64 emulation will do the same.

Other than this, Windows ARM comes with all Windows DLLs in 3 versions: ARM32, ARM64, x86. In addition there is a smaller subset hybrid-DLLs containing ARM64 and x86 code aka CHPE.

What x86 SIMD instruction sets are supported by the ARM transpiler?
As of now, the following features are supported:
AES, CX8, FXSR, MMX, POPCNT, SSE, SSE2, SSE3, SSE4.1

Future high-performance ARM CPUs are dropping Aarch32 alltogether. Is Windows on ARM ready for this? Does it currently have the ability to boot and run on an Aarch64-only ARM CPU?

In theory ARM32 is only needed when starting and running an ARM32 process. All Kernel and Background processes are ARM64...so might just work. Practically, Windows might check CPU features at boot and rejects to boot if 32bit is missing - or it just disables the creation of ARM32 processes feature and happily continue booting.
I guess we will see what's happening when trying to boot Windows ARM in a VM under AS Macs.

How many apps for ARM Windows require Aarch32 to work?

While anyone can just create an ARM32 app using Visual Studio - the reality is that all recent native ARM apps are all ARM64. Most existing ARM32 apps are leftovers from Windows RT.
Also the upcoming .NET 5 core runtime+SDK will have ARM64 support, while ARM32 support will be dropped.
 
Last edited:
  • Love
Reactions: leman and jdb8167

Gerdi

macrumors 6502
Apr 25, 2020
449
301
Good thinking! It didn't come to my mind that VMs could still run with older OSX versions. Thanks a lot, that pushes me even more towards moving into the ARM era.

How can VMs on AS Macs run older versions of OSX, if older versions of OSX do not support ARM?
 
  • Wow
Reactions: eulslix

ChrisA

macrumors G5
Jan 5, 2006
12,917
2,169
Redondo Beach, California
.. how hard can the rest be?

This is exactly the bottleneck for many developers, their code depends on some well-tested and mature library and if the library is not ported to ARM they can't move to ARM. large software projects have large lists of dependencies where some libraries depend on other libraries and so on. You just have to wait until the authors of these libraries get around to releasing ARM versions.

This is the same thing that held up the move to Python 3. How hard is it to move from 2 to 3? It is simple for the code you wrote but impossible if the packages you need are not yet moved to Python 3.

In the worst-case your software depends on a library that is no longer maintained so waiting will not work. Now you have a big problem and either have to re-write your code to use some other library or you have to become the next maintainer of the abandoned library.
 
  • Like
Reactions: jdb8167

ChrisA

macrumors G5
Jan 5, 2006
12,917
2,169
Redondo Beach, California
Good thinking! It didn't come to my mind that VMs could still run with older OSX versions. Thanks a lot, that pushes me even more towards moving into the ARM era.

No. An Arm-based host id NOT going to run an Intel-based OS in a virtual machine. Of course one could write an emulator to run X86 code on Arm. This is what Rosetta does. But Rosetta emulates a user-space for running apps, not for running another OS.

The bottom line is you just buy a cheap C if you need to run a Windows App or a used Mac if you need to run an old MacOS.
 

jdb8167

macrumors 601
Nov 17, 2008
4,859
4,599
Just to get this straight, i do not work for Microsoft - so i do not have any insights into future projects like x86-64 support.



JIT is generating Aarch64 code. You can see this when connecting a debugger to an x86 process on an ARM device. Also all CHPE Dlls containing ARM64 code.
It is also save to assume that x86-64 emulation will do the same.

Other than this, Windows ARM comes with all Windows DLLs in 3 versions: ARM32, ARM64, x86. In addition there is a smaller subset hybrid-DLLs containing ARM64 and x86 code aka CHPE.


As of now, the following features are supported:
AES, CX8, FXSR, MMX, POPCNT, SSE, SSE2, SSE3, SSE4.1



In theory ARM32 is only needed when starting and running an ARM32 process. All Kernel and Background processes are ARM64...so might just work. Practically, Windows might check CPU features at boot and rejects to boot if 32bit is missing - or it just disables the creation of ARM32 processes feature and happily continue booting.
I guess we will see what's happening when trying to boot Windows ARM in a VM under AS Macs.



While anyone can just create an ARM32 app using Visual Studio - the reality is that all recent native ARM apps are all ARM64. Most existing ARM32 apps are leftovers from Windows RT.
Also the upcoming .NET 5 core runtime+SDK will have ARM64 support, while ARM32 support will be dropped.
Thanks for this. Even if the current version of Windows 10 on ARM can’t yet boot, it sounds like the path to a working version is relatively straightforward. This is encouraging. It was never clear to me why Microsoft bothered with Aarch32 in the first place.
 

curmudgeonette

macrumors 6502a
Jan 28, 2016
586
496
California
As of now, the following features are supported:
AES, CX8, FXSR, MMX, POPCNT, SSE, SSE2, SSE3, SSE4.1


Some speculation on patent expirations:

AMD64 was "announced in 1999 with a full specification released in August 2000." Thus it is now off patent.

SSE2 was introduced with the Pentium 4. The P4 was launched November 20th, 2000. Thus, in six weeks, SSE2 is certainly off patent.

A few years back, there were rumors that 64 bit x86 emulation was being held back due to patent issues. The above two items show that some patent barriers are falling right now. This may provide a hint as to release dates!

And now I'm going to wildly speculate: What if Microsoft's 64 bit emulator/translator and Apple's 64 bit emulator/translator are one and the same? As in, perhaps it has been a joint effort.
 

Gerdi

macrumors 6502
Apr 25, 2020
449
301
Some speculation on patent expirations:

AMD64 was "announced in 1999 with a full specification released in August 2000." Thus it is now off patent.

SSE2 was introduced with the Pentium 4. The P4 was launched November 20th, 2000. Thus, in six weeks, SSE2 is certainly off patent.

A few years back, there were rumors that 64 bit x86 emulation was being held back due to patent issues. The above two items show that some patent barriers are falling right now. This may provide a hint as to release dates!

And now I'm going to wildly speculate: What if Microsoft's 64 bit emulator/translator and Apple's 64 bit emulator/translator are one and the same? As in, perhaps it has been a joint effort.

Since when has an ISA ever been patented? You can patent a certain implementation or method but neither would be violated by a SW emulator.
 

Yebubbleman

macrumors 603
May 20, 2010
6,024
2,616
Los Angeles, CA
I am far from an expert, but it says, As it stands right now, ARM64 PCs can run three kinds of apps: 32-bit native ARM apps, 64-bit native ARM apps, and 32-bit emulated Intel (x86) apps. So to the MacOS, isn't the app that matters say, Parallels, a well-behaved native app, and it uses the 32-bit x86 emulation in Windows ARM to run the Windows app? The Windows app runs inside Parallels (or VMWare), not as part of the MacOS..

If Apple's SoCs can't run 32-bit ARM code, then we're likely not seeing Windows 10 for ARM64 being able to run on Apple Silicon (virtualized or native) if there's any 32-bit ARM code present. I'd imagine that currently that IS the case for Windows 10 for ARM64; however, with ARM announcing that they'll be dropping 32-bit instruction sets even from their own designs, I'd imagine that Microsoft will adapt accordingly, thereby making it all possible.

This means almost nothing about reviving native Bootcamp ("raw" Windows on hardware). There is a more than decent chance Apple simply does not support the boot context that Windows on ARM needs ( UEFI). So what is added to the post Windows boot context doesn't matter one lick.

You're talking about just a bootloader. That's it. It's not like Microsoft can't just make a different bootloader or like Apple can't provide an emulation layer (a la the original CSM support baked into the EFI of early Intel era Macs for Boot Camp) to make Microsoft's EFI bootloader to work.

More so this is further validation that Apple's virtualized guest OS strategy path will work just fine. Windows 10 on ARM with 64bit emulation of Windows apps layered on top will probably work just fine for 85+% of the possible Window on ARM userbase out there for the next several years. Once that mode is a mainstream "norm" , Apple won't need that much more.

Honestly, that all remains to be seen. Windows virtualization (as far as x86-64 is concerned) has come a long way in the past decade. You can do all but the most recent and resource intensive gaming and work via virtualization (assuming you're running a Mac with decent graphics) now. How this will translate to ARM64 and Apple Silicon remains to be seen. My guess is that it will be fine. But even then, native booting will always offer an edge, even if it's a very slight one.

Great! Just about time. Looking forward to it in VMware Fusion for in ARM-based Apple silicon Macs.

Bro, I wouldn't hold your breath. It doesn't look like VMware is solid about it and even if they were, you need Microsoft to play ball unless you're only interested in running Debian or any of the few other Linux distros that have a non-server ARM64 variant out (Ubuntu isn't even among them yet).

Legacy Windows apps aren't AArch32 though. Does Windows' built-in x86 emulation actually switch the Arm to 32-bit mode or does it emulate everything and keep it in 64-bit mode?

Legacy Windows apps aren't what I'd be worried about. Microsoft may very well have 32-bit ARM components running on Windows 10 for ARM64 just because they didn't need to be 64-bit. That's the kind of code that can cause problems in bringing Windows 10 for ARM64 to an Apple implementation of ARM that has no 32-bit instruction set whatsoever.

Not being able to Boot Camp games will push devs to port them to run natively on Metal.

While nice in theory, that idea will fail in practice pretty hardcore. tvOS based Apple TVs have console calibur graphics with no console titles to match. Gaming on the Apple TV is a joke (and it's not because it doesn't support decent controllers, because it very much does). Devs weren't playing ball with Apple when they supported industry standard technologies like OpenGL. What makes you think they're going to be on-board with Metal just because Apple took Boot Camp off the menu?
 

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,866
Some speculation on patent expirations:

AMD64 was "announced in 1999 with a full specification released in August 2000." Thus it is now off patent.

SSE2 was introduced with the Pentium 4. The P4 was launched November 20th, 2000. Thus, in six weeks, SSE2 is certainly off patent.

A few years back, there were rumors that 64 bit x86 emulation was being held back due to patent issues. The above two items show that some patent barriers are falling right now. This may provide a hint as to release dates!

And now I'm going to wildly speculate: What if Microsoft's 64 bit emulator/translator and Apple's 64 bit emulator/translator are one and the same? As in, perhaps it has been a joint effort.

Why would Apple work with Microsoft on this one? Apple doesn't like external dependencies for core technologies. They even got burned on emulation being an external dependency during the previous Mac CPU transition. (They licensed Rosetta 1 from Transitive, and the timeline for when they removed Rosetta 1 from Mac OS X matches up quite well with when IBM bought Transitive and stopped selling its software as a product.)

Also, the thread title concerns a future emulator. Microsoft's current shipping emulator only runs 32-bit x86, Apple's Rosetta 2 only runs 64-bit x86. Not very similar.


The final nail in the coffin (that I know of, anyways) is a bit more technical. Apple's Rosetta 2 isn't software-only: they added a special feature to their ARM core which gives Rosetta 2 a huge boost.

This has to do with memory ordering - the rules which govern the order in which writes from one CPU to memory become visible to itself and other CPUs. x86 uses one of the more restrictive ordering models, known as x86-TSO (total store ordering). ARM's memory ordering model is considerably less restrictive.

This matters a lot because x86 software often takes shortcuts which (in a multiprocessor environment) would be bugs on other architectures with looser ordering rules, but aren't bugs on x86-TSO.

If you're writing an x86-on-ARM emulator, and you want it to support multiple CPUs with interprocess communication, you're going to have to do something about this. The only remedy available in a generic ARM CPU is to "fence" every write to memory to force it to complete in program order. Unfortunately, this hurts performance a lot - extra instructions, and they're slow ones.

So, Apple added a mode bit to their cores. (It's present in the A12Z already, which makes it clear that while A12Z is first and foremost an iPad chip, it was also planned as an ARM Mac testbed.) When set, the memory interface for that core obeys x86-TSO rules rather than the less restrictive ARM rules. Rosetta 2 takes advantage of this. That's a big part of why it's so fast.

Microsoft's emulator, however, has to run on generic ARM CPUs. It has to use slow software emulation of x86-TSO ordering. It also means there's going to be a ton of differences in emulator design compared to Rosetta 2.

Since when has an ISA ever been patented? You can patent a certain implementation or method but neither would be violated by a SW emulator.

Intel has tried to assert that its patents cover software emulation of x86. Might just be saber rattling, might not hold up in court if it comes to that. We'll see.

 

leman

macrumors Core
Oct 14, 2008
19,517
19,664
Just to get this straight, i do not work for Microsoft - so i do not have any insights into future projects like x86-64 support.



JIT is generating Aarch64 code. You can see this when connecting a debugger to an x86 process on an ARM device. Also all CHPE Dlls containing ARM64 code.
It is also save to assume that x86-64 emulation will do the same.

Other than this, Windows ARM comes with all Windows DLLs in 3 versions: ARM32, ARM64, x86. In addition there is a smaller subset hybrid-DLLs containing ARM64 and x86 code aka CHPE.


As of now, the following features are supported:
AES, CX8, FXSR, MMX, POPCNT, SSE, SSE2, SSE3, SSE4.1



In theory ARM32 is only needed when starting and running an ARM32 process. All Kernel and Background processes are ARM64...so might just work. Practically, Windows might check CPU features at boot and rejects to boot if 32bit is missing - or it just disables the creation of ARM32 processes feature and happily continue booting.
I guess we will see what's happening when trying to boot Windows ARM in a VM under AS Macs.



While anyone can just create an ARM32 app using Visual Studio - the reality is that all recent native ARM apps are all ARM64. Most existing ARM32 apps are leftovers from Windows RT.
Also the upcoming .NET 5 core runtime+SDK will have ARM64 support, while ARM32 support will be dropped.

Thank you, it has been very informative! What you wrote makes me more optimistic about seeing virtualized Windows on the new Macs sometime in 2021.
 

Waragainstsleep

macrumors 6502a
Oct 15, 2003
612
221
UK
While nice in theory, that idea will fail in practice pretty hardcore. tvOS based Apple TVs have console calibur graphics with no console titles to match. Gaming on the Apple TV is a joke (and it's not because it doesn't support decent controllers, because it very much does). Devs weren't playing ball with Apple when they supported industry standard technologies like OpenGL. What makes you think they're going to be on-board with Metal just because Apple took Boot Camp off the menu?


I expect Apple to offer a combination of custom hardware and software that others might find hard to match. I also think there will be scope for games that offer a range of ways to interact with the game via different devices that other platforms won't be able to so easily.
I wouldn't write it off just yet.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.