Valve plays the long game — started ARM translation layer initiative a decade ago
The Steam Frame is a Trojan horse carrying Arm’s gaming future.
www.theverge.com
Last week, the Verge has conducted interview with Valve's Pierre-Loup Griffais, one of the architects behind SteamOS and the Steam Deck. It is a good read, Pierre mentioned that Valve has been funding for Fex emulator since 2018. Pierre also explained the questions below:
- Why Arm?
- When you say “include all those options,” you’re thinking there’ll be other Arm SteamOS devices, too?
- When and how are you attracting companies to build those other kinds of devices?
- Is the Arm version of SteamOS a separate operating system?
- Can you break down those layers for us? When I’m playing a Windows game on my Steam Deck, how does that work?
- How is Wine different from Proton?
- How does all of this change when we’re running Windows games on Arm?
- How does this compare to other Windows-on-Arm emulation, like Prism for Windows on Arm?
- How long has Valve supported Fex and to what degree?
- Valve started Fex?
- The Steam Frame runs Android apps, but it’s not Android running on the headset. How?
- Will there be SteamOS phones? Will you bring non-gaming apps into the store in a big way?
- Is Arm the future of handheld gaming, or is it just something for headsets?
In case people can't assess the article, I have linked the Youtube video from NerdNest who explained each answer in detail:
What wasn’t widely reported: Valve is behind Fex itself.
In an interview, Valve’s Pierre-Loup Griffais, one of the architects behind SteamOS and the Steam Deck, tells The Verge that Valve has been quietly funding almost all the open-source technologies required to play Windows games on Arm. And because they’re open-source, Valve is effectively shepherding a future where Arm phones, laptops, and desktops could freely do the same. He says the company believes game developers shouldn’t be wasting time porting games if there’s a better way.
Remember when the Steam Deck handheld showed that a decade of investment in Linux could make Windows gaming portable? Valve paid open-source developers to follow their passions to help achieve that result. Valve has been guiding the effort to bring games to Arm in much the same way: In 2016 and 2017, Griffais tells me, the company began recruiting and funding open-source developers to bring Windows games to Arm chips.
Fex lead developer Ryan Houdek tells The Verge he chatted with Griffais himself at conferences those years and whipped up the first prototype in 2018. He tells me Valve pays enough that Fex is his full-time job. “I want to thank the people from Valve for being here from the start and allowing me to kickstart this project,” he recently wrote.
Is the Arm version of SteamOS a separate operating system?
It’s the same exact OS components, the same exact Arch Linux base, all the same updater, all the same technologies. Depending on form factors, you might have different pieces of software that you want to be running or not running — some of them make more sense on a handheld, some more sense on a headset, some in desktop form factor, but all of those options are always available and part of the core OS.
So when you’re looking at SteamOS on Arm, you’re really looking at the same thing. Instead of downloading the normal Proton that’s built for x86 and targets x86 games, it will also be able to download a Proton that’s Arm-aware, that has a bulk of its code compiled for Arm and can also include the Fex emulator.
How does all of this change when we’re running Windows games on Arm?
First there’s an intermediate step. Anytime you’re setting up code segments, Wine is now going to try and see if it’s x86 or Arm code, because some Windows apps are targeted towards Arm or might include mixed segments, or a DLL might bundle both Arm and x86 code. If there’s x86 code, it will put it in the right spot with enough functionality to jump in and out of the Fex emulator.
The Fex emulator’s sole purpose is to provide compatibility with x86. So it takes the x86 code, and uses a just-in-time translator to emit Arm code that does the exact same thing. Proton built for Arm support will make sure that whenever it’s setting up code segments, any code segment that’s x86 will properly jump into Fex so it can be run through Fex instead of the native CPU.
All the game code is translated by Fex, so it has a bit of work to do. But when the game jumps into an API call, like, say, issuing a draw call to the graphics driver through the Vulkan or D3D12 API, it will immediately jump into Arm-native code. Because you’re running Arm-native code built as part of Proton, the area you have to emulate is only the code that’s owned by the game itself. So the performance hit of any emulation stops as soon as you cross that API boundary between Windows and Linux.
The Steam Frame runs Android apps, but it’s not Android running on the headset. How?
It’s a similar compatibility layer as Proton, just targeted at Android. There’s not a whole Android API and implementation there, just a subset mostly targeted towards games, providing the right libraries on our side, so that things typically contained in an Android executable can run. They’re already targeting Arm, so you don’t need to do emulation on the code that’s contained there. You just need to set up the libraries and executable in such a way that it can run in the first place.