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
    63
    ·
    edit-2
    2 days 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?

    • drspod@lemmy.ml
      link
      fedilink
      arrow-up
      36
      arrow-down
      2
      ·
      2 days ago

      is there any ARM chipset out there that can deliver performance on par with the Steam Deck’s CPU

      Yes, but they’re made by Apple.

      • MyNameIsAtticus@lemmy.world
        link
        fedilink
        arrow-up
        11
        arrow-down
        1
        ·
        2 days ago

        I got a M1 Pro MacBook a couple weeks ago. I’m astonished at how fucking powerful those thing are. An Intel laptop I had with similar specs would start screaming for mercy for any heavy Programming work I’d do. The MacBook just shrugs it off. Fans don’t even come on

        • Dudewitbow@lemmy.zip
          link
          fedilink
          arrow-up
          6
          ·
          edit-2
          1 day ago

          keep in mind, for the longest time Intels processors were still on Intels fab. a huge chunk of the efficiency/performance gains was less x86 > arn and more Intel Fab > TSMC. even to a lesser extent, compare the snapdragon 8 gen 1 to the snapdragon 8+ gen 1. Samsung wasn’t as far behind tsmc (compared to intel) at the time and both designs basically are the same chip but implemented at two different fabs.

          It also involves how manufacturers decide how to handle price performance. Most laptop manufacturers see any performance lost due to clocking it low bad for sales(so they agressively clock it higher for performance) causing louder fans. Apple takes the opposite approach, where they tune it for noise performance because they control what people see on their graphs (while being misleading, by essentially never including anything faster than it) and asking users to pay top dollar for the top tier fab runs (apple essentially has top cut priority at TSMC) so they always get to see the bleeding edge efficiency nodes/performance before anyone else does at the higher cost to them(which is then passed on to the consumer)

          • fuckwit_mcbumcrumble@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            3
            ·
            1 day ago

            AMD is on a much better process node than Intel, but their battery life still isn’t as good as Apple’s. Particularly under low to medium loads. My M1 MBP easily gets 12 hours of battery life under a real load. My AMD powered ThinkPad is closer to 7 hours, and my Intel machines get like 4, on a good day.

            • Dudewitbow@lemmy.zip
              link
              fedilink
              arrow-up
              5
              arrow-down
              1
              ·
              edit-2
              23 hours ago

              the thing is, people are attributing it to ARM, rather than how Apple handles their OS. its the sole reason why Snapdragon X Elite wasn’t that great on Windows, because ultimately, the problem wasn’t about x86 vs Arm, but it was about how windows handled low powered operations. If valve makes a piece of hardware that’s arm based, they clearly aren’t going to be using OSX for any reason. You can tell by the discussion because you can easily name which generation processor you run on a MBP, but fail to mention the cpu models for either the AMD nor intel powered machines and gives the aura of equivalent playing fields when it fundamentally wont.

              Just because Apple with their heavily controlled OS space can make the transition to ARM work flawlessly for batterylife doesn’t mean it applies to all other ARM devices. Arm definitely does some aspects better, but it’s not by default better in every situation due to the nature of the environment that surrounds said hardware is. The power efficiency only exists if all applications are recompiled to target said hardware. For a gaming device, it’s not going to be very useful because very few games that Valve would target have an arm based build. You get into the problem that emulators have. things like proton is a translation layer and suffers much less overhead (e.g why mobile phones can do switch emulation for instance(arm to arm based translation layer) but no phone remotely will do ps3 emulation (arm to ibm cell processor), despite console wise, being roughly the same in performance.

              It’s the sole reason why Apples dev kit for games doesn’t run games like proton does(where it can legit run games better than original if its using an older API). Because architecture changes isn’t just a translation layer, theres a layer of emulation to it, which while can be hardware accelerated if done right, is never 1:1 like a translation layer is.

              Want to test how your MBP battery life is on a different environment not entirely tailored to Apple, run Asahi Linux for example and you will notice immediately that the battery life isn’t the same. (asahi linux is a fedora based distro tailored for M series machines)

              • redfellow@sopuli.xyz
                link
                fedilink
                arrow-up
                2
                ·
                15 hours ago

                This comment makes it seem like we don’t already have Modern Arm Windows based laptops that have excellent battery life, comparable to Apple M devices.

                But we do.

                • Dudewitbow@lemmy.zip
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  15 hours ago

                  me mentioning the snapdragon x elite is the situation. it doesnt have good battery life in the usecase this while topic is about (gaming). your comment sounds like you read the reviews and didnt understand which functions excelled in battery life, and which ones didnt.

                  the whole point is just because something is Arm, doesnt automatically make it more efficient in all usecases. what’s the point in a gaming device thats less efficient when its gaming.

                  • redfellow@sopuli.xyz
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    3 hours ago

                    Windows Arm laptops are currently just as bad for gaming as all the other arm based laptops, so it’s weird to single them out. That’s why I didn’t think you were only speaking about gaming any more.

    • Fubarberry@sopuli.xyzOPM
      link
      fedilink
      English
      arrow-up
      11
      arrow-down
      1
      ·
      2 days 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.

        • entropicdrift@lemmy.sdf.org
          link
          fedilink
          arrow-up
          3
          ·
          18 hours 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
      2 days 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
        13
        ·
        2 days 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
          ·
          18 hours 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.