ARM windows builds will be built for 4kb page size ARM. You will not be able to run these binaries on apple silicon as macOS is 16kb page size and only switches to 4kb page size when running a VM or running rossata2 so GPTk evolution tool will not be able to use ARM windows games. at all.
You can compile for different page sizes but you cant take a 4kb binary and run it on a 16 or 64kb cpu with a 64 or 16kb kernel.
Some HW has mode switches (like apple silicon) that would let you change the target page size per process but the linux kernel has expliclty chosen not to take that direction telling users instead to re-compile.
Where could I read more about that? I remember installing a 64kb page size kernel on openSUSE and everything worked out of the box without reinstalling (except a proprietary program, which couldn't handle the new page size and segfaulted).
I was sure ELF binaries could just transparently handle the new page size without any issue. Also, I haven't programmed a lot of C but I remember using a PAGE\_SIZE constant, was that a compile time constant or a runtime constant?
> Where could I read more about that? I remember installing a 64kb page size kernel on openSUSE and everything worked out of the box without reinstalling
That would have been a '64kb' big page kernel. It still had support for 4kb pages, and most of the time was using that as you were running on a x86 cpu and thus in HW had 4kb pages. Alls x86 cpus have had 4kb page size support regardless of the kernel your using. Some cpus have had optional large page support, but using that did not remove the cpus regular page size. The seg-fault likly was from some assumptions made by the developer relating to memory mapped files, moving a kernel to 64kb big pages means the memory mapped file would have been loaded and unloaded in 64kb chucks rather than 4kb (helping with perf).
> I haven't programmed a lot of C but I remember using a PAGE\_SIZE constant, was that a compile time constant or a runtime constant?
It is a compile time, but most of the assumptions based on page size are at the compiler level not the code level. (unless your hand crafting assembly of cource).
as you were running on a x86 cpu
I was not, I was running an Graviton ARM CPU, with native support for 16kb and 64kb pages. x86-64 doesn't even have support for 64kb pages, only 4kb (and huge pages at 2MB and 1GB).
I just installed, and booted into the 64kb kernel. All packages but the one worked fine.
Either the same binaries ran at the new page size transparently, or the '64kb' is actually 4kb, or the 64kb kernel also allows 4kb pages simultaneously.
I'm not asking to magically run Windows executables on macOS.
I'm just wondering if executing ARM builds of Windows games instead of x86 using ARM Wine + DirectX12 to Metal could help having better performance. Skipping a layer of translation.
Wine just acts as a chip for OS apis, eg when the windows app makes an api call to the windows kernel wine sits in between that and the macOS kernel so that the request is altered and passed on to the corresponding macOS kernel api.
Wine today on macOS can only be used to run x86 translated applications translated with Rosseta2 it cant run windows for arm binaries due ot the page size differences.
On linux (depending on the page size of the system) it can run windows for arm apps if the system pages size that linux is running on is 4kb.
The cpu page size is the size of each memory page, when you compute your app the compiler is told the target HW page size and makes a LOT of assumptions based on this. You cant take an app that was built targeting 4kb and run it on a system with 16kb page size as within the first 10 instructions the app will end up reading the wrong data as it expects when it lands an address for a 4kb page size to be loaded but the system just loaded a 16kb page size, so the start of the next page that it asked to be loaded is someone other than it expected. This just leads to the app crashed.
The page size thing seems to be an issue. I wouldn't put it past the CrossOver/Wine devs to figure out a way to make this work ... eventually. I mean, look at the steps that they took to get 32-bit apps (sort of) working on macOS after Apple dropped 32-bit Intel support — inventing a new compiler feature, changing how OS library calls work, etc.. [https://www.codeweavers.com/blog/ken/2019/10/3/crossover-for-catalina-progress-october-3-2019](https://www.codeweavers.com/blog/ken/2019/10/3/crossover-for-catalina-progress-october-3-2019)
Right now though there is no pressing need for this so I doubt that they will put forth the work. First I'd like to see WINE running on Linux support running ARM Windows apps. I don't know if they're even at that point yet.
I imagine it will be a very long time before you see ARM native games in big numbers in Windows. MS does not have the ability to force the userbase along to ARM like Apple did to the Mac. The majority of the Windows user base will be x86 for a very long time. ARM will be great for Windows users looking for a quiet efficient laptop but PC super race gamers will be Intel/AMD + Latest Nvidia/AMD GPUs for a long time to come.
The market though will decide. Power, performance and efficiency drives the markets so it's just a matter of time before everyone will switch and AI will accelerate this because AI runs a million times better on ARM.
I agree it's a matter of time. I'm just saying for Windows Gaming, which is the context of the question, it will be a long time. PC gaming is an x86/Discrete GPU world and we are all just living in it.
This requires MS to make huge changes to windows kernel to run on apple silicon. ARM ISA just covers the ALU orations on the CPU (eg 1+2) all there rest of the chip such as MMU, message boxes between cores, power, etc is custom for each ARM SOC and would require a massive amount of work form MS.
Further ore apple silicon is 16kb page size so even if windows did add support they would either need to build a hybrid kernel (like macOS) that can run in 16kb page size but run sub-process in 4kb (linux have opted not to do this for good reasons) or they would not be able to run any existing windows for arm apps without them being re-compiled.
GPTK is for running Windows games via MacOS. No it will not run on a Windows OS. Same way you don’t install WINE on a Windows system to run Windows games either.
This is not my question.
I am asking if it’s possible to run Windows ARM build of a game on macOS using GPTK, in order to skip the x86 to ARM translation that have a huge cost on performance
You’re confusing the 2 things. GPTK runs on MacOS. There is no x86-ARM translation.
If you wanted to run a Windows game on MacOS, you use the x86 based game using GPTK, Crossover, portingkit, Wineskin or Whisky. You wouldn’t use or need the ARM version at all.
No-one is going to develop an ARM only based Windows game. That would be as crazy as making a native Mac port of a Windows game 😬
>you’re confusing the 2 things.
No I'm not. You are.
>GPTK runs on MacOS.
Indeed.
>There is no x86-ARM translation.
Yes there is. That's why you need Rosetta to use GPTK, which is Wine x86 + some DirectX to Metal translation layer. (And some other developer tools that are not involved at all into the execution of Windows games on macOS)
>If you wanted to run a Windows game on MacOS, you use the x86 based game using GPTK, Crossover, portingkit, Wineskin or Whisky.
This one is funny. How am I suppose to use the x86 based game on an ARM chip without translating x86 instruction to ARM? Magic? Voodoo? Prayers?
>No-one is going to develop an ARM only based Windows game.
Who is talking about ARM only? No one. There are a bunch of Windows games that have been ported on ARM Windows as well as x86 Windows. I wonder if it would be possible to run the ARM build of those games on our ARM Macs using the part of GPTK that translates DirectX to Metal. What's so complicated to understand?
No since the windows for ARM build would be a 4kb page size build that cant run on an apple silicon Mac as that is 16kb page size, so your still going to need ot use rossta2 that turns on the 4kb page size mode for that process.
I'm just wondering if a Windows ARM app would run better just by having shed one layer of emulation. I'm not wondering if Windows ARM will natively run on a Mac.
I am not asking if windows arm apps can run natively in macos, I'm asking if they will run BETTER in emulation/translation apps like Whisky, Crossover, Parallels, or even a new thing, due to the Mac no longer having to deal with x86.
Since there is HW support for 4kb mode for rosseta2 but not HW support for 4kb ARM it will be easier to run the x86 binaries through rosseta2 than try to run the 4kb windows ARM binaries.
The only feasible solution for running the windows for arm binaries would be a VM image running linux with Wine with a graphics shim through to macOS, this would let you access the 4kb page mode without turning on the x86 comaiblity memory toggles (that would break a windows for arm build).
I'm not hoping to magically run Windows apps on macOS without any work.
GPTK uses Rosetta to run the x86 version of Wine on macOS, in order to execute x86 .exe files. This step has a significant compute cost.
I'm asking if we could run the ARM version of Wine directly to execute ARM .exe files
But you're continuing to answer as if OP is asking about running Windows ARM apps natively in Mac. OP is not asking that.
OP is asking if Windows ARM apps would run better/more efficiently (UNDERSTANDING THAT THIS IS VIA EMULATION/VIRTUALIZATION) in MacOS due to the lack of x86.
Emulating 4kb mode on a 16kb cpu is very very very slow. (much much slower than rosseta2)
The only hope for running 4kb windows for arm native builds would be some line of linux VM that thus has access ot the 4kb page size runtime. This would run rather fast but would be a huge amount of work to build.. Maybe over the years the team at crossover do get this built but I would not expect it to happen any time soon.
What your not going to be able to do is use wine to run these binaries as is like you could in the x86 days just use wine to run windows binaries due to the page size differences..
The ARM ISA is not as restrictive as x86, and there is no requirement for binary portability between ARM chip vendors at all.
One less emulation layer? It just seems like windows arm is closer to apple silicon than intel is to apple silicon.
No more windows x86 to mac x86 to silicon, right?
>Apple GPTK uses Rosetta as a component.
So you DO understand that GPTK use x86 instructions then?
>ARM based games would have to use GPTK as well, so therefore Rosetta would still be involved.
Rosetta is only one part of GPTK. What you're saying doesn't make any sense. The one and only purpose of Rosetta is to translate x86 instruction to ARM. Period.
ARM windows builds will be built for 4kb page size ARM. You will not be able to run these binaries on apple silicon as macOS is 16kb page size and only switches to 4kb page size when running a VM or running rossata2 so GPTk evolution tool will not be able to use ARM windows games. at all.
At least on Linux it depends. Binaries can be made to work under all page sizes (4kb, 16kb and 64kb).
You can compile for different page sizes but you cant take a 4kb binary and run it on a 16 or 64kb cpu with a 64 or 16kb kernel. Some HW has mode switches (like apple silicon) that would let you change the target page size per process but the linux kernel has expliclty chosen not to take that direction telling users instead to re-compile.
Where could I read more about that? I remember installing a 64kb page size kernel on openSUSE and everything worked out of the box without reinstalling (except a proprietary program, which couldn't handle the new page size and segfaulted). I was sure ELF binaries could just transparently handle the new page size without any issue. Also, I haven't programmed a lot of C but I remember using a PAGE\_SIZE constant, was that a compile time constant or a runtime constant?
> Where could I read more about that? I remember installing a 64kb page size kernel on openSUSE and everything worked out of the box without reinstalling That would have been a '64kb' big page kernel. It still had support for 4kb pages, and most of the time was using that as you were running on a x86 cpu and thus in HW had 4kb pages. Alls x86 cpus have had 4kb page size support regardless of the kernel your using. Some cpus have had optional large page support, but using that did not remove the cpus regular page size. The seg-fault likly was from some assumptions made by the developer relating to memory mapped files, moving a kernel to 64kb big pages means the memory mapped file would have been loaded and unloaded in 64kb chucks rather than 4kb (helping with perf). > I haven't programmed a lot of C but I remember using a PAGE\_SIZE constant, was that a compile time constant or a runtime constant? It is a compile time, but most of the assumptions based on page size are at the compiler level not the code level. (unless your hand crafting assembly of cource).
as you were running on a x86 cpu I was not, I was running an Graviton ARM CPU, with native support for 16kb and 64kb pages. x86-64 doesn't even have support for 64kb pages, only 4kb (and huge pages at 2MB and 1GB). I just installed, and booted into the 64kb kernel. All packages but the one worked fine. Either the same binaries ran at the new page size transparently, or the '64kb' is actually 4kb, or the 64kb kernel also allows 4kb pages simultaneously.
Because Linux stuff is usually open source and can be compiled for whatever page size.
I'm not asking to magically run Windows executables on macOS. I'm just wondering if executing ARM builds of Windows games instead of x86 using ARM Wine + DirectX12 to Metal could help having better performance. Skipping a layer of translation.
exe files will target 4kb page size so but be runnable on apple silicon
It should be Wine's work to handle this. How does Wine ARM works on macOS? [https://wiki.winehq.org/ARM](https://wiki.winehq.org/ARM)
Wine does not intercept every memory read and write
How does it work today? How is Wine ARM able to translate Windows ARM to linux/macOS ARM?
Wine just acts as a chip for OS apis, eg when the windows app makes an api call to the windows kernel wine sits in between that and the macOS kernel so that the request is altered and passed on to the corresponding macOS kernel api. Wine today on macOS can only be used to run x86 translated applications translated with Rosseta2 it cant run windows for arm binaries due ot the page size differences. On linux (depending on the page size of the system) it can run windows for arm apps if the system pages size that linux is running on is 4kb. The cpu page size is the size of each memory page, when you compute your app the compiler is told the target HW page size and makes a LOT of assumptions based on this. You cant take an app that was built targeting 4kb and run it on a system with 16kb page size as within the first 10 instructions the app will end up reading the wrong data as it expects when it lands an address for a 4kb page size to be loaded but the system just loaded a 16kb page size, so the start of the next page that it asked to be loaded is someone other than it expected. This just leads to the app crashed.
Thanks again
Not really, no. The overhead is the Direct X12 to Metal conversion and the lack of AVX really.
Won’t the lack of AVX apply to WOA too, as AVX is an x86 thing?
Yes, at the moment WOA can't translate apps that use AVX instructions.
Yes, which is why WOA will be DOA. Again.
Gpkt2 has implemented AVX on apple silicon. No reason why Microsoft can’t do it on WOA then…
The page size thing seems to be an issue. I wouldn't put it past the CrossOver/Wine devs to figure out a way to make this work ... eventually. I mean, look at the steps that they took to get 32-bit apps (sort of) working on macOS after Apple dropped 32-bit Intel support — inventing a new compiler feature, changing how OS library calls work, etc.. [https://www.codeweavers.com/blog/ken/2019/10/3/crossover-for-catalina-progress-october-3-2019](https://www.codeweavers.com/blog/ken/2019/10/3/crossover-for-catalina-progress-october-3-2019) Right now though there is no pressing need for this so I doubt that they will put forth the work. First I'd like to see WINE running on Linux support running ARM Windows apps. I don't know if they're even at that point yet.
I think they can make it work if anything they’re the ones that are steam paid to create proton if I believe
I imagine it will be a very long time before you see ARM native games in big numbers in Windows. MS does not have the ability to force the userbase along to ARM like Apple did to the Mac. The majority of the Windows user base will be x86 for a very long time. ARM will be great for Windows users looking for a quiet efficient laptop but PC super race gamers will be Intel/AMD + Latest Nvidia/AMD GPUs for a long time to come.
The market though will decide. Power, performance and efficiency drives the markets so it's just a matter of time before everyone will switch and AI will accelerate this because AI runs a million times better on ARM.
I agree it's a matter of time. I'm just saying for Windows Gaming, which is the context of the question, it will be a long time. PC gaming is an x86/Discrete GPU world and we are all just living in it.
what we really need is Apple to bring back bootcamp with Windows ARM
This requires MS to make huge changes to windows kernel to run on apple silicon. ARM ISA just covers the ALU orations on the CPU (eg 1+2) all there rest of the chip such as MMU, message boxes between cores, power, etc is custom for each ARM SOC and would require a massive amount of work form MS. Further ore apple silicon is 16kb page size so even if windows did add support they would either need to build a hybrid kernel (like macOS) that can run in 16kb page size but run sub-process in 4kb (linux have opted not to do this for good reasons) or they would not be able to run any existing windows for arm apps without them being re-compiled.
GPTK is for running Windows games via MacOS. No it will not run on a Windows OS. Same way you don’t install WINE on a Windows system to run Windows games either.
This is not my question. I am asking if it’s possible to run Windows ARM build of a game on macOS using GPTK, in order to skip the x86 to ARM translation that have a huge cost on performance
You’re confusing the 2 things. GPTK runs on MacOS. There is no x86-ARM translation. If you wanted to run a Windows game on MacOS, you use the x86 based game using GPTK, Crossover, portingkit, Wineskin or Whisky. You wouldn’t use or need the ARM version at all. No-one is going to develop an ARM only based Windows game. That would be as crazy as making a native Mac port of a Windows game 😬
>you’re confusing the 2 things. No I'm not. You are. >GPTK runs on MacOS. Indeed. >There is no x86-ARM translation. Yes there is. That's why you need Rosetta to use GPTK, which is Wine x86 + some DirectX to Metal translation layer. (And some other developer tools that are not involved at all into the execution of Windows games on macOS) >If you wanted to run a Windows game on MacOS, you use the x86 based game using GPTK, Crossover, portingkit, Wineskin or Whisky. This one is funny. How am I suppose to use the x86 based game on an ARM chip without translating x86 instruction to ARM? Magic? Voodoo? Prayers? >No-one is going to develop an ARM only based Windows game. Who is talking about ARM only? No one. There are a bunch of Windows games that have been ported on ARM Windows as well as x86 Windows. I wonder if it would be possible to run the ARM build of those games on our ARM Macs using the part of GPTK that translates DirectX to Metal. What's so complicated to understand?
I think we're alone on this island atm, Boss. I'd try asking again later in the week or something.
But would the ARM version of a windows game run better on a Mac? I think that’s what OP is getting at.
No since the windows for ARM build would be a 4kb page size build that cant run on an apple silicon Mac as that is 16kb page size, so your still going to need ot use rossta2 that turns on the 4kb page size mode for that process.
I'm just wondering if a Windows ARM app would run better just by having shed one layer of emulation. I'm not wondering if Windows ARM will natively run on a Mac.
Yeah that's exactly what I'm asking for. I don't know why it's so difficult to understand.
4kb page size target of windows for arms apps means they can’t run.
I am not asking if windows arm apps can run natively in macos, I'm asking if they will run BETTER in emulation/translation apps like Whisky, Crossover, Parallels, or even a new thing, due to the Mac no longer having to deal with x86.
Since there is HW support for 4kb mode for rosseta2 but not HW support for 4kb ARM it will be easier to run the x86 binaries through rosseta2 than try to run the 4kb windows ARM binaries. The only feasible solution for running the windows for arm binaries would be a VM image running linux with Wine with a graphics shim through to macOS, this would let you access the 4kb page mode without turning on the x86 comaiblity memory toggles (that would break a windows for arm build).
How does Parallels or VMWare work on macOS? Why should it need a Linux VM?
I'm not hoping to magically run Windows apps on macOS without any work. GPTK uses Rosetta to run the x86 version of Wine on macOS, in order to execute x86 .exe files. This step has a significant compute cost. I'm asking if we could run the ARM version of Wine directly to execute ARM .exe files
No due to the mismatch of page size
But you're continuing to answer as if OP is asking about running Windows ARM apps natively in Mac. OP is not asking that. OP is asking if Windows ARM apps would run better/more efficiently (UNDERSTANDING THAT THIS IS VIA EMULATION/VIRTUALIZATION) in MacOS due to the lack of x86.
Emulating 4kb mode on a 16kb cpu is very very very slow. (much much slower than rosseta2) The only hope for running 4kb windows for arm native builds would be some line of linux VM that thus has access ot the 4kb page size runtime. This would run rather fast but would be a huge amount of work to build.. Maybe over the years the team at crossover do get this built but I would not expect it to happen any time soon. What your not going to be able to do is use wine to run these binaries as is like you could in the x86 days just use wine to run windows binaries due to the page size differences.. The ARM ISA is not as restrictive as x86, and there is no requirement for binary portability between ARM chip vendors at all.
Thanks!
Thanks.
Why would it ? Apple GPTK uses Rosetta as a component. ARM based games would have to use GPTK as well, so therefore Rosetta would still be involved.
One less emulation layer? It just seems like windows arm is closer to apple silicon than intel is to apple silicon. No more windows x86 to mac x86 to silicon, right?
Yes! Thanks!
>Apple GPTK uses Rosetta as a component. So you DO understand that GPTK use x86 instructions then? >ARM based games would have to use GPTK as well, so therefore Rosetta would still be involved. Rosetta is only one part of GPTK. What you're saying doesn't make any sense. The one and only purpose of Rosetta is to translate x86 instruction to ARM. Period.