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
    66
    ·
    edit-2
    2 months 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
      40
      arrow-down
      2
      ·
      2 months 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
        13
        arrow-down
        1
        ·
        2 months 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 month 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
            5
            ·
            1 month 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
              6
              arrow-down
              1
              ·
              edit-2
              1 month 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
                ·
                1 month 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
                  2
                  ·
                  edit-2
                  1 month 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.

    • Fubarberry@sopuli.xyzOPM
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      1
      ·
      2 months 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
        ·
        2 months 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
      8
      arrow-down
      2
      ·
      edit-2
      2 months 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
        ·
        2 months 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.

  • helenslunch@feddit.nl
    link
    fedilink
    arrow-up
    41
    arrow-down
    3
    ·
    2 months ago

    This is almost certainly meant for the next Valve VR headset

    Based on what? Looks more likely to be Android to me. Or it could be an ARM Steam Deck.

    ARM has so much better power efficiency than x86

    x86 has pretty much caught up already if you look at the latest mobile chips from AMD and Intel.

    • 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.

    • Fubarberry@sopuli.xyzOPM
      link
      fedilink
      English
      arrow-up
      8
      ·
      2 months ago

      Part of how they’re identifying that proton arm and steam Waydroid exists is that the tools are being used to test VR games uploaded to steam, or were uploaded in a batch of other VR assets.

      I fully hope to see this apply to Steam Deck/Chromebooks/Android/etc, but right now any hints of these have been VR specific. We haven’t seen the Proton ARM before, but previous leaks about Waydroid have also all been VR related.

    • Bogasse@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      2 months ago

      About Intel catching up I might add that even if it proves to be true, this was not something that seemed to be expected. Valve might have been working on IR for a few years now?

    • wallmenis@lemmy.one
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      I mean… It mentions waydroid so it is probably going to use that for android compatibility…

  • Vincente@lemmy.world
    link
    fedilink
    arrow-up
    32
    arrow-down
    2
    ·
    edit-2
    2 months ago

    Amazing! I hope I can buy a Linux on ARM Steam Deck someday. It should be more efficient, lighter, and smaller.

    • Lemzlez@lemmy.world
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      5
      ·
      2 months ago

      And perform terribly because it’d have to emulate x86 because there’s no native ARM games (for Windows).

      There’s no way there’ll be an ARM steam deck, unless valve wants to build an android gaming handheld for some reason.

      • chonglibloodsport@lemmy.world
        link
        fedilink
        arrow-up
        10
        arrow-down
        2
        ·
        2 months ago

        Perform terribly on modern AAA titles, sure, but that’s a tiny % of the total Steam library. A lot of people these days don’t even bother with new AAA titles, instead playing older games or indie games. I bet Valve knows this and is working on the ARM transition specifically because of this fact.

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

          That’s fair. I do mostly play AAA games on my deck, so “yet another android gaming handheld” isn’t at all appealing to me though.

      • Vincente@lemmy.world
        link
        fedilink
        arrow-up
        6
        arrow-down
        1
        ·
        edit-2
        2 months ago

        And the second example is Rosetta 2 for gaming on ARM-based Macs. You mentioned that some emulators running x86 games (on ARM) are inefficient.

        That’s the point: emulation is not the same as translation.

        Translation is generally more efficient than emulation and can sometimes even match or exceed the performance of native execution.

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

          Apple’s M-chips have dedicated hardware to accelerate rosetta 2 (support for x86 memory ordering), please stop using rosetta2 as a show of what x86 on ARM can do, as it is a vertically integrated piece of software that is not indicative of the current market for anyone outside of apple.

          Just take a look at windows on those new qualcomn chips - when they do the translation, the performance is underwhelming to say the least.

          Yes, it will improve, but it currently does not exist outside of Apple.

          • Vincente@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 month ago

            The translation on ARM macs is actually strongly related to Valve because Rosetta 2 and the Game Porting Toolkit are based on the open-source Proton, which was developed by Valve. So, it’s not an Apple-exclusive technology; it’s closely tied to Valve. Valve could also collaborate with AMD or others to develop custom SoCs, similar to what Apple has done. I believe Valve has the ability and ambition to do the same thing, but even better than Apple. Because they have done it once with the Steam Deck.

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

              Rosetta and proton are two completely different layers.

              Game porting toolkit is indeed also based on wine, but that’s only the conversion of directX to ogpl or vulkan (using metalVK in Apple’s case)

              Rosetta is a completely separate harware accelerated (as in, the chips have dedicated hardware for this) translation layer for x86 to ARM

              Given the lengths they had to go through to get even this custom APU, I can only imaging the difficulty in procuring a first-gen ARM offering from AMD.

              I swear, this is just the “VR is really here, and it’ll replace conventional gaming!” Debate all over again. I’d be surprised if it happens in the next two years. After that? Maybe, if x86 doesn’t catch up more than it already has (which I fully expect it to do).

              • Vincente@lemmy.world
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                1 month ago

                I never said it would happen in the next two years. I just said that it’s a possible path, and apparently, it has no chance of happening in two years. Valve’s next step in two years is apparently to update the Steam Deck 2 with AMD x86 chips. A 5- to 10-year period is what I expect.

                I won’t talk about this anymore with you. Bye.

                And hardware acceleration is not as important as you emphasize. A traditional ARM chip running native ARM and cross-platform games, and some x86/Windows/DirectX games that don’t need hardware acceleration to translate on Linux on ARM is competitive enough in the gaming market. At least it’s more ecologically rich than Android games (if you have any doubt, just look at the Nintendo Switch!), and it would function as a PC too.

                Some games don’t need hardware acceleration to be translated. Others that do need it can’t be translated, just like some games don’t support SteamOS. Overall, it doesn’t affect the Steam Deck’s success!

      • Vincente@lemmy.world
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        edit-2
        2 months ago

        Which you said is a backward compatibility issue. Some games that are developed only for x86 or the DirectX API have performance issues, but other games that support cross-platform or cross-platform APIs like Vulkan do not have this problem.

        An obvious example is the Nintendo Switch, which goes against your argument.

        Because of backward compatibility, x86’s efficiency still can’t match ARM’s. That’s why I said games run on ARM would be more efficient, lighter, and smaller (when they natively support ARM).

        If you have any doubts, just look at the Nintendo Switch.

          • Vincente@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 month ago

            That’s a backward compatibility issue, which means some games developed for x86, Windows, or DirectX just can’t be translated without glitches. This means not every game developed for x86, Windows, or DirectX can be translated well on ARM.

            I said that ‘some games that are developed only for x86 or the DirectX API have performance issues’; I didn’t say ‘every game.’ I mean that games with native support or cross-platform support are certainly better than those developed only for DirectX, Windows, or x86.

            For example, many games developed exclusively for Windows/DX can’t be played on SteamOS. So how can you be certain that games developed for x86, Windows, or by DirectX would be totally well supported on ARM?

            And you mentioned Qualcomm. Fine, look at the Qualcomm X Elite SoC computers. Do they run x86, Windows, or DirectX software or games steadily, efficiently, and well? Do they have many glitches when running Windows and x86 software?

    • Zamundaaa@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      6
      arrow-down
      3
      ·
      2 months ago

      This myth that ARM is more efficient needs to die already. The ISA has almost no impact on efficiency, and especially no impact on gaming, where the GPU is the much more important thing.

      • Blisterexe@lemmy.zip
        link
        fedilink
        arrow-up
        3
        ·
        1 month ago

        I always figured the reason arm chips tend to be more effecient is that theyve been developped for phones

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

          The architecture was originally developed for desktop PCs, but they discovered it was incredibly efficient at the time (late 80s, early 90s), so Apple partnered with ARM to develop it for the Newton.

          The first commercial device with an ARM chip that I remember fondly was a Gameboy Advance.

  • Mwa@lemm.ee
    link
    fedilink
    English
    arrow-up
    17
    ·
    2 months ago

    Imagine someone can game on their Mac using ashi linux or heck even your phone

  • OhYeah@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    17
    arrow-down
    2
    ·
    1 month ago

    A part of me does hope that they’ll hold off and release riscv products instead (headset and deck). I know box64 can already translate to riscv and I remember reading that FEX was working on it (android is also getting riscv support so waydroid should too?). Given their focus on linux it has to be on their radar

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

      In the shorter-term the issue is the lack of sufficiently powerful commercially-available RISC-V hardware for the level of gaming people expect out of a Steam Deck or VR headset, which ARM already has a number of SOCs capable of.

      I don’t doubt that the work will continue but Valve isn’t likely to pour time or money into it until they think the hardware is there.

  • soulsource@discuss.tchncs.de
    link
    fedilink
    arrow-up
    15
    ·
    1 month ago

    ARM based Deck would be a huge improvement to battery life. Don’t get your hopes up too high. You will need an emulation layer like FEX of Box64, and unlike WINE those do have quite a substantial overhead.

    It is impressive how far those emulators have come, especially since they got the option to use native libraries instead of emulated ones, but the game logic itself will always need emulation…

    This doesn’t mean it can’t be done, it just means that the ARM CPU needs to be pretty fast to counter the emulation overhead, and that’s why I have my doubts about the energy efficiency…

    (Btw: I have tried running several AMD64 games on my A311D powered MNT Reform laptop with Box64. It’s impressive how well the emulation runs, and how many games are actually playable already. However, I also encountered a lot of games that don’t reach enjoyable FPS on that hardware. With a faster ARM chip though…)

    • tiddy@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 month ago

      With a big dev like valve backing it they could probably implement a pretty impressive JIT/cacheing scheme - of course nothing beats native but this gap will close over time

      • soulsource@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 month ago

        Yep. The big question is if the gap will close enough that ARM chips indeed end up delivering better power efficiency with emulation than an AMD64 chip that delivers the same performance without emulation.

        My bets would be on the native AMD64 chip ending up more power efficient. To be honest, I would not bet too much money though.

  • Dudewitbow@lemmy.zip
    link
    fedilink
    arrow-up
    15
    ·
    2 months ago

    i mean better efficiency is one thing, but having “so much better power efficiency” isn’t that large, especially under load. Arms major advantage is efficiency while doing lighter workloads, which is kinda the antithesis of a gaming device would be.

    What arm based designs excel at is if whatever workload utilizes some of the specific built hardware in them, which is why the modems and camera image processor on the snapdragon cpus are better than x86, because x86 designs dont really have dedicated hardware for those functions integrated fully(intel cpus do to some extent)

    • Fubarberry@sopuli.xyzOPM
      link
      fedilink
      English
      arrow-up
      9
      arrow-down
      2
      ·
      2 months ago

      Arms major advantage is efficiency while doing lighter workloads, which is kinda the antithesis of a gaming device would be.

      That’s important too for gaming devices. It’s great the the steam deck can get 6-8 hours on low power games like Stardew Valley. A significant problem with many of the windows competitors is that they don’t see significantly better battery life at low loads. The original ROG Ally gets about 1.5 hours in a game like Cyberpunk 2077, but only gets 2-2.5 hours in a game like Stardew Valley.

      • Dudewitbow@lemmy.zip
        link
        fedilink
        arrow-up
        11
        ·
        edit-2
        2 months ago

        the lighter workloads isn’t like stardew valley levels workloads, it would be like watching a video level loads. Just being arm doesn’t outright make it that battery friendly, its like the non application use(e.g sleep, super basic app) where the battery level is better. The qualcomm laptop reviews kind of show that platform when its battery life is mildly better than last gen amd/intel chips and worse under gaming. Qualcomm rushed the release because they new they needed to release before AMD’s Strix Point and Intels Lunar Lake to make it look like they were more efficient. (X elite was on TSMC N4, Meteor lake was on N5/N6, Phoenix and Strix were on N4X, but they knew AMD would have the highest NPU performance had it released first.

        the BIGGEST flaw that the arm based designs have that isn’t tegra is that their graphics drivers are inferior to both Nvidia and AMD, and graphics drivers play a huge role in whether something works correctly or not.

  • solberg@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    1
    ·
    1 month ago

    Exciting! I remember commenting about the next Steam Deck being ARM a couple months ago and a few people replied that it was unlikely haha

    Hope this can work in Asahi Linux at some point too 👀

      • sour@feddit.org
        link
        fedilink
        English
        arrow-up
        8
        ·
        1 month ago

        I don’t think a budget deck is likely tbh. The non oled deck already goes for 250 on sales. To make a clear distinction the budget one would need to be <150. And I don’t think that’s feasible with all the other hardware necessary alone. Except making it a lot smaller which I don’t think is a good approach.

        • PlasticExistence@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 month ago

          Well you may be right and Valve may only be aiming to support some of the already-existing handhelds out there that are ARM based.

          Valve does know how to play the long game on support, so time will tell.

  • milicent_bystandr@lemm.ee
    link
    fedilink
    arrow-up
    12
    ·
    1 month ago

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

    Doesn’t that require something quite different?

    Proton is improved (matured?) WINE, right? And Wine Is Not an Emulator - the point being it doesn’t emulate hardware, it translates instruction sets. From for-Windows x86 to Linux x86. Can you do that cross cpu architecture?

    • stormeuh@lemmy.world
      link
      fedilink
      arrow-up
      11
      ·
      1 month ago

      Well, not exactly… WINE is a compatibility layer for syscalls between the x86 Windows API and (among others) the x86 Linux API, quite similar to how DXVK translates from DirectX to Vulkan.

      What proton does is combine utilities like Wine and DXVK into a user friendly bundle, along with contributing substantially to the projects it bundles to make them interoperate well.

      This looks to me like they want to bundle another utility, which does fast emulation of x86 user code on an ARM Linux system. Another commentator mentioned they are using FEX for this, which looks to me to do the same core task as qemu-user, but more focused on x86 to ARM and generally user-friendlier. That emulator could then be used to run x86 Wine on ARM.

      The way qemu-user and FEX emulate one ISA on another is actually very cool btw. They realise massive speed gains by intercepting syscalls and executing them directly, instead of emulating a whole x86 Linux system.

      • xavier666@lemm.ee
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 month ago

        Since Microsoft also wants x86 apps to work on their Qualcomm powered Windows laptops, can this project help Microsoft in some way?

        • stormeuh@lemmy.world
          link
          fedilink
          arrow-up
          4
          ·
          1 month ago

          No, not that much. The emulation of the syscalls are specific to Linux, so none of that is usable on Windows. They could reuse the emulator, but it seems likely they would write their own from scratch so they can keep everything closed source. Obligatory: fuck Microsoft.

      • soulsource@discuss.tchncs.de
        link
        fedilink
        arrow-up
        2
        ·
        1 month ago

        by intercepting syscalls and executing them directly

        Not only syscalls. FEX and Box64 also allow using native libraries instead of emulating them. That leaves basically only the game logic to be emulated.

        • stormeuh@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          1 month ago

          I didn’t know that, thanks! That’s actually very impressive, and given how efficient qemu-style emulators are, I wouldn’t be surprised to see near-native performance despite a little bit of overhead from emulating game logic.

  • JohnWorks@sh.itjust.works
    link
    fedilink
    arrow-up
    7
    ·
    2 months ago

    This is something I’ve always wanted from them ever since I learned that the current ways that emulate x86 use proton on top of a bunch of other stuff. Would love if this was able to be used on phones.

    • somethingp@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      I know you’re referring to a VR headset but my mind immediately started imagining standalone over-ear headphones that can play all PC games through a purely audio interface. Imagine the accessibility possibilities lol