5 ms·

I wouldn't count on many developers going back to update old games with ARM support. It's more likely that the community will work to build some sort of Box86 +

I wouldn't count on many developers going back to update old games with ARM support. It's more likely that the community will work to build some sort of Box86 + Proton stack to get games working, which should get a lot of the classics working[0]. From there, I think the struggle will be getting Box86 to run fast enough for modern games. Apple's ARM CPUs have great IPC, but that can still get annihilated when it's forced to simulate SIMD/AVX instructions. I assume Apple has some sort of vector acceleration framework in Apple Silicon, but it will take time and effort to reverse-engineer and implement. Things are certainly looking better than they did a couple years ago, but getting ARM to run x86 code faster-than-native is an uphill battle. Maybe even an impossible one, but I've been surprised before (like with DXVK). [0] Crysis on a Rockchip ARM SOC, for example: https://youtu.be/k6C5mZvanFU?t=1069 https://youtu.be/k6C5mZvanFU?t=1069

nicoburns 4y ago
> I assume Apple has some sort of vector acceleration framework in Apple Silicon, but it will take time and effort to reverse-engineer and implement. I'm pretty sure it's just vanilla ARM NEON so I don't think it will take any reverse engineering. The Apple Silicon GPU is custom, but the CPU is just minor extensions to (and compatible with) AArch64. Rumour has it that this is because AArch64 was designed by Apple and donated to ARM (who Apple has close relationship with being that they were a founding member).
- saagarjha 4y ago
  Apple support NEON (and uses it for most SIMD code) but it also has other proprietary ISA extensions for e.g. matrix multiply.
  - shaunsingh0207 4y ago
    note that the proprietary extensions are extremely unlikely to gain linux support though, unless upstream arm adopts something similar though amx won’t help out with emulation much
- smoldesu 4y ago
  Interesting, that's what I was curious about. NEON is a bit slow last I checked, but at least Apple is sticking to spec here. It does make me wonder how much performance is left on the table for ARM architectures that want to emulate x86, though. ...it also raises the question of how emulated titles fare against translated ones. It would be fascinating to see how something like Dark Souls Remastered performs through Yuzu vs DXVK on Apple Silicon.
kitsunesoba 4y ago
It's a little frustrating how it's the norm in the game industry for companies to toss a binary over the wall and maybe patch it for a short period after release (not a given, ports in particular are vulnerable to being forever stuck at 1.0), with significant technical updates being out of the question until it's been long enough for them to try to sell you a remaster. Not having any experience in that industry, I wonder what the driving forces of this are. I suspect it's some combination of incredibly brittle codebases that cease to build if glanced at the wrong way and aversion to spending anything on games post-release.
- jacquesm 4y ago
  I much prefer that model over services that suddenly disappear.
  - kitsunesoba 4y ago
    The "binary abandonment" model can have effectively the same result, though. An example that come to mind immediately is how much of a mess it is to get games that were built with Games for Windows Live like the PC port of Fable 3 running on modern Windows. It's possible, but there's a ridiculous number of hoops to jump through, none of which would be necessary if Microsoft shipped a quick and dirty update that pulled out the Games for Windows Live dependency.
    - howinteresting 4y ago
      GFWL games are really an exception -- most games on Windows or Proton work fine years down the road.
  - izacus 4y ago
    Not to mention the predatory subscription models that are rampant in mobile for software that is equally as broken, just costing more.
- stonemetal12 4y ago
  >aversion to spending anything on games post-release. I am pretty sure that is the answer. Unless the game is Cyberpunk levels of unplayable, there is no money in post release support unless it is bundled with DLC or GOTY releases. Back in the day it was pretty commonly sited figure that like 90% of a game's revenue came in the first 3-4 weeks of release. DLC and "seasons" are an attempt to stretch it out and make more off a single release, but I haven't heard how well that works.
58028641 4y ago
The problem with Box86 is that it requires 32 bit ARM, which Apple Silicon does not support.

nicoburns 4y ago

> I assume Apple has some sort of vector acceleration framework in Apple Silicon, but it will take time and effort to reverse-engineer and implement. I'm pretty sure it's just vanilla ARM NEON so I don't think it will take any reverse engineering. The Apple Silicon GPU is custom, but the CPU is just minor extensions to (and compatible with) AArch64. Rumour has it that this is because AArch64 was designed by Apple and donated to ARM (who Apple has close relationship with being that they were a founding member).

saagarjha 4y ago
Apple support NEON (and uses it for most SIMD code) but it also has other proprietary ISA extensions for e.g. matrix multiply.
- shaunsingh0207 4y ago
  note that the proprietary extensions are extremely unlikely to gain linux support though, unless upstream arm adopts something similar though amx won’t help out with emulation much
smoldesu 4y ago
Interesting, that's what I was curious about. NEON is a bit slow last I checked, but at least Apple is sticking to spec here. It does make me wonder how much performance is left on the table for ARM architectures that want to emulate x86, though. ...it also raises the question of how emulated titles fare against translated ones. It would be fascinating to see how something like Dark Souls Remastered performs through Yuzu vs DXVK on Apple Silicon.

kitsunesoba 4y ago

It's a little frustrating how it's the norm in the game industry for companies to toss a binary over the wall and maybe patch it for a short period after release (not a given, ports in particular are vulnerable to being forever stuck at 1.0), with significant technical updates being out of the question until it's been long enough for them to try to sell you a remaster. Not having any experience in that industry, I wonder what the driving forces of this are. I suspect it's some combination of incredibly brittle codebases that cease to build if glanced at the wrong way and aversion to spending anything on games post-release.

jacquesm 4y ago
I much prefer that model over services that suddenly disappear.
- kitsunesoba 4y ago
  The "binary abandonment" model can have effectively the same result, though. An example that come to mind immediately is how much of a mess it is to get games that were built with Games for Windows Live like the PC port of Fable 3 running on modern Windows. It's possible, but there's a ridiculous number of hoops to jump through, none of which would be necessary if Microsoft shipped a quick and dirty update that pulled out the Games for Windows Live dependency.
  - howinteresting 4y ago
    GFWL games are really an exception -- most games on Windows or Proton work fine years down the road.
- izacus 4y ago
  Not to mention the predatory subscription models that are rampant in mobile for software that is equally as broken, just costing more.
stonemetal12 4y ago
>aversion to spending anything on games post-release. I am pretty sure that is the answer. Unless the game is Cyberpunk levels of unplayable, there is no money in post release support unless it is bundled with DLC or GOTY releases. Back in the day it was pretty commonly sited figure that like 90% of a game's revenue came in the first 3-4 weeks of release. DLC and "seasons" are an attempt to stretch it out and make more off a single release, but I haven't heard how well that works.

58028641 4y ago

The problem with Box86 is that it requires 32 bit ARM, which Apple Silicon does not support.