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

  • BananaTrifleViolin@lemmy.world
    link
    fedilink
    English
    arrow-up
    18
    ·
    2 months ago

    Intel claims to have caught up with the upcoming Lunar Lake series but still to be seen.

    That may be too late for whatever new device Valve is working on as given the lead time for such devices they may already have committed to an architecture for devices next year.

    Also running X86 games on Arm devices is not likely to be efficient. I doubt the energy efficiency of Arm chips would outweigh the overhead of X86 to Arm translation?

    But it’s all speculation - even without hardware, getting Proton to work with Arm is good for steam regardless of any specific devices. For example it would allow steam to push the compatability tools onto Mac devices and even potentially mobile devices. Makes sense for Valve to do this without it meaning anything more that it being a god idea in itself.

    • Pasta Dental@sh.itjust.works
      link
      fedilink
      arrow-up
      6
      ·
      2 months ago

      It depends for the translation speed, if they only make a single device, they can likely do what apple does and improve their translation layer (FEX) to use specific instructions of the CPU they are using. Apples Rosetta is very efficient at what it does

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

        Even Rosetta still gives up 10%+ efficiency compared to a native compilation of the same program. I’m not saying it’s not viable, but in a resource constrained (especially battery-constrained) device 10% is a lot.