Interesting, I didn't know they'd added an Windows/ARM build. Makes some sense though, WoW has always been one of the best about broad platform/arch support… macOS/PPC and Windows/x86 versions were both available from day one and have stayed in lockstep the whole time, and it was among the first games to make both the PPC → x86 jump and x86 → ARM jump on Macs. Have heard that they had Linux builds internally early on too.
It offers native x86, Windows on ARM, and Apple Silicon versions.
I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that.
This is neat, and exciting that Windows emulation tooling is progressing! It seems like there’s a lot of work hardware vendors would need to do in order to make Win/Arm viable for game devs. I really wonder if that’s ever going to happen.
TL;DR the author attempts to measure the ratio between native and emulated performance using Microsoft Prism on Windows. His measurements suggest that the emulated performance is very close to native performance.
Though I am not skeptical of the authors methodology, I do suspect that the ARM64 build of WoW may not be as "optimized" as the x64 build. This is because in some of his workloads the emulated game actually outperformed the native game.
I'm tentatively excited for the new Snapdragon X2 Elite. Or I would be if any of us could ever afford RAM prices ever again.
The high end model has a 192-bit memory bus, a 3 channel design. 12+6 cores but very big/big more than less big/little. 53MB L3 cache is quite healthy. 80TOps NPU (int8). 9533 MT/s 192-bit memory for 228GB/s which is nipping right at Strix Halo & Nvidia Spark's heels. 12x PCIe 5.0, 4x PCIe 4.0, and "3x USB-C" 40Gb/s (hopefully not some shared bandwidth cop out). And some kind of pretty big GPU. The specs here are quite promising.
And Qualcomm has started taking Linux drivers somewhat more seriously. Linux & mesa drivers are arriving now for previous Snapdragon X Elite & looking pretty promising. That said, this whole Device Tree world is hell, and never going to be good, and Qualcomm direly needs to get religion there & get some ServerReady type ACPI + UEFI compatibility standardized in the products, and stop OEMs from shipping these awful embedded-style non-PC things.
I'm excited to see ARM finally actually show up with something competitive. Alas though, those RAM prices. What a sad buzzkill, and man this is going to take forever to work out.
The compiler is also a factor, as MSVC's ARM64 backend is less mature than the x64 backend, while the xtajit(64) emulators in Windows were written by emulation veterans. But even then, I've typically seen a ~25% penalty between a native optimized ARM64 build and an emulated optimized x64 build. Major optimized code paths being disabled or suboptimal in the ARM64 port would definitely be more plausible, especially in licensed third-party libraries.
I’m curious if WoW is using any newer x86 instruction sets like AVX. I’ve been testing some math benchmarks on ARM emulating x64, and saw very little performance improvement with the AVX2+FMA builds, compared to the SSE4.x level. (X64 v2 to v3.) It was unexpected.
It’s the first Windows build with Prism and the first time they’ve introduced AVX(2) support, so I wonder simply if the performance isn’t there yet. I’ve found very little info online about this.
AVX(2)'s main advantage is 256-bit width, since many of its operations are simply concatenated 128-bit ops (weird for ops like VPALIGNR), and cross-lane operations are expensive. NEON, on the other hand, only supports 128-bit ops, so AVX operations need to be split by the emulator.
I'd expect more of a gain from enabling FMA, but that's assuming the program actually got built to use FMA -- it needs to either use it explicitly or have relaxations to allow the contraction. Oryon has 4 x 128-bit NEON pipes with 3c latency fadd and 4c latency fmul/fma, so it easily ends up latency bottlenecked unless there are plenty of independent calculations.
x86 laptops are shipping with buggy firmware. It's easier to update device tree than to patch firmware. The less work delegated to hardware manufacturer - the better, if you ask me. Just give me PCB and datasheets.
I've been very curious about this since they added Windows on ARM support. Admittedly there hasn't been a really performant SoC to see how it stacks up to Apple Silicon. The Apple Silicon version runs so well I had hoped they brought that same performance jump to Windows on ARM. One thing I noticed about the Apple Silicon version was that it loads the game world significantly faster than x86. Even with lots of heavy addons. I'm curious if that mirrors to Windows ARM.
Also curious if Battle.net client has the same bug as Apple Silicon where it consistently needs to run a game "update" after closing the game. The client is still x86 even on macOS so I'm wondering if this is an translation issue that could be fixed with a proper native client.
17 comments
[ 2.5 ms ] story [ 35.9 ms ] threadI think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that.
https://us.support.blizzard.com/en/article/76459
This is neat, and exciting that Windows emulation tooling is progressing! It seems like there’s a lot of work hardware vendors would need to do in order to make Win/Arm viable for game devs. I really wonder if that’s ever going to happen.
Though I am not skeptical of the authors methodology, I do suspect that the ARM64 build of WoW may not be as "optimized" as the x64 build. This is because in some of his workloads the emulated game actually outperformed the native game.
The high end model has a 192-bit memory bus, a 3 channel design. 12+6 cores but very big/big more than less big/little. 53MB L3 cache is quite healthy. 80TOps NPU (int8). 9533 MT/s 192-bit memory for 228GB/s which is nipping right at Strix Halo & Nvidia Spark's heels. 12x PCIe 5.0, 4x PCIe 4.0, and "3x USB-C" 40Gb/s (hopefully not some shared bandwidth cop out). And some kind of pretty big GPU. The specs here are quite promising.
And Qualcomm has started taking Linux drivers somewhat more seriously. Linux & mesa drivers are arriving now for previous Snapdragon X Elite & looking pretty promising. That said, this whole Device Tree world is hell, and never going to be good, and Qualcomm direly needs to get religion there & get some ServerReady type ACPI + UEFI compatibility standardized in the products, and stop OEMs from shipping these awful embedded-style non-PC things.
I'm excited to see ARM finally actually show up with something competitive. Alas though, those RAM prices. What a sad buzzkill, and man this is going to take forever to work out.
It’s the first Windows build with Prism and the first time they’ve introduced AVX(2) support, so I wonder simply if the performance isn’t there yet. I’ve found very little info online about this.
I'd expect more of a gain from enabling FMA, but that's assuming the program actually got built to use FMA -- it needs to either use it explicitly or have relaxations to allow the contraction. Oryon has 4 x 128-bit NEON pipes with 3c latency fadd and 4c latency fmul/fma, so it easily ends up latency bottlenecked unless there are plenty of independent calculations.
All I want is something like a Macbook Air, but running Linux - long battery life, acceptable performance, an OS that respects me.
Besides, I'd look forward to testinf with the nea ARM emulation layer Valve is developing.
Also curious if Battle.net client has the same bug as Apple Silicon where it consistently needs to run a game "update" after closing the game. The client is still x86 even on macOS so I'm wondering if this is an translation issue that could be fixed with a proper native client.