This would presumably let x86 windows games run on ARM hardware.

This is almost certainly meant for the next Valve VR headset, but ARM has so much better power efficiency than x86 that a future ARM based Deck would be a huge improvement to battery life.

Also see this tweet:

VR games that have already secretly pushed Android ARM builds onto the Steam Store are ran via Waydroid (androidARM to LinuxARM)

VR games that do not have an ARM build on Steam (windows x86) are being translated/emulated via ProtonARM and FEX

Edit: here’s gamingonlinux coverage of this info, includes some more information

  • leopold@lemmy.kde.social
    link
    fedilink
    arrow-up
    62
    ·
    edit-2
    1 month ago

    Well, Steam and Proton both already run on top of FEX or Box64 on ARM Linux, but it’s nice to see an official effort from Valve.

    Also, does ARM still have better battery life when all of the machine code has to be translated from x86? That adds a not insubstantial amount of CPU overhead, which does hurt battery life.

    And perhaps most importantly, is there any ARM chipset out there that can deliver performance on par with the Steam Deck’s CPU (even after factoring in the overhead of the x86 JIT) at a viable price for a Steam Deck successor?

    • Fubarberry@sopuli.xyzOPM
      link
      fedilink
      English
      arrow-up
      11
      arrow-down
      1
      ·
      1 month ago

      Also, does ARM still have better battery life when all of the machine code has to be translated from x86? That adds a not insubstantial amount of CPU overhead, which does hurt battery life.

      No idea, and that’s a pretty good question. The again some games run better on proton through Linux than they do on windows, so the performance overhead isn’t that bad.

      • PrivateNoob@sopuli.xyz
        link
        fedilink
        arrow-up
        6
        ·
        1 month ago

        True, but I feel like having to reroute x86 calls to ARM will produce more overhead than just Proton.

        • entropicdrift@lemmy.sdf.org
          link
          fedilink
          arrow-up
          4
          ·
          1 month ago

          Depends on how it’s implemented. If they have a version of Proton that translates all x86 windows syscalls to ARM Linux, some operations could be extremely efficient.

          There’s definitely got to be more overhead overall, though. Especially for devices with memory page sizes other than 4K, like the M-series Apple chips do (they use 16K as their page size), likely a VM will need to be sandwiched in there to ensure memory alignment. It’ll more fully be emulation and not just translation.

    • Pup Biru@aussie.zone
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      2
      ·
      edit-2
      1 month ago

      does ARM still have better battery life when all of the machine code has to be translated from x86

      afaik macos/rosetta is more efficient than native windows/x86, but that could be down to OS integration, or any number of confounding factors… i’d suggest though that x86 windows applications sometimes run better and more efficiently on alternative platforms, even with the translation layers - whether that’s down to the instruction set or a combination of factors

      • TheGrandNagus@lemmy.world
        link
        fedilink
        English
        arrow-up
        12
        ·
        1 month ago

        IIRC, the M chips also have a couple of specific hardware accelerators for some parts of x86 code that ARM devices would usually struggle with. That’s something that other ARM chips (presumably) don’t have.

        • entropicdrift@lemmy.sdf.org
          link
          fedilink
          arrow-up
          1
          ·
          1 month ago

          It’s more like a built-in hardware emulation mode than anything else. Modern ARM chips use out of order execution as the default, whereas x86 uses ordered execution as the default. M-series and Snapdragon X chips have a little flag that can be passed to tell the hardware to run in in-order mode instead of out-of-order mode.