So last week we mentioned that Stadia was going to introduce a solution to run Windows games unmodified on Linux, and not using Proton as Google was apparently building their own thing.

Turns out the conference was just yesterday and this is what they have presented:

You can watch the whole thing but here’s the key take aways if you don’t have time.

It starts with a refresher about what Stadia actually is:

• It’s x64 hardware, using Linux together with Vulkan and Pulseaudio.
• However, the emphasis is on “Linux” as being a very customized version of it, stripped of any kind of desktop component. There is no support for 32 bits applications either, and they have a proprietary interface for dealing with input.

For porting, there are a few solutions already:

• You can easily publish your games to Stadia if you use Unity or Unreal Engine integrations.
• Use the Stadia Porting toolkit, which integrates DXVK, to make it easier to port your Windows games to Stadia. The feedback from developers is that it’s really hard.

64 bits applications

So… they came up with a third option. Binary translation, using OS layer translation. Basically making it look to the application that it runs in a Windows environment, even though it’s not.

There are limitations to this approach, however:

Only 64 bits support, no networking, no DRM, and single process.

It’s an interative porting process: you run the game until you find where it breaks, and then you implement functions to fill the gap one by one.

There are hundreds of Windows functions to implement to run a game. But once a function is implemented, it’s done for all other games too. It gets easier the more games are ported. You would also need to implement other APIs such as graphics and audio, but this is where DXVK and Faudio come to the rescue:

32 bits Support

Since Stadia does not have any kind of support for 32 bits application, they need to treat 32 bits applications differently.

The plan is to actually decompile the 32 bits binary and then compile it again to x64 architecture!

Problem is, it’s not straightforward to find the code within a binary, since it can contain pretty much anything. There are tools that help doing that:

There are additional complexities with 32 bits programs, such as the use of FPUs, the memory allocation limitation, etc…

Overall the offline conversion process seems to work well in their experience as they ported several AAA titles with it already (not named).

They went further and developed another solution for 32 bits translation by building a runtime instead, which makes it possible to run 32 bits applications without any offline decompilation. This brings better compatibility overall but demands a constant maintenance of the blocks cache.

Why Build their Own Tech

This is probably the most insightful part of the presentation. Most people are wondering why they didn’t just use WINE/Proton in order to implement this in the first place. Well, they had their reasons:

First, the Linux version they used is very stripped down (probably to ensure it can be spun up very very quickly). Therefore most of the dependencies used by projects such as WINE are not included. They don’t need to impleement window management, or alt-tabbing since it is useless for the specific purpose of Stadia applications.

Second, the hardware is specific the Stadia, along with custom drivers and Vulkan extensions. They may have other capabilities than you regular x64+GPU box.

Third, WINE is a massive project and they don’t need most of what it does when it comes to just running games. WINE does implement a tremendous amount of logic for GUI applications outside of gaming.

Finally, debugging WINE needs its own workflow, which they did not find very productive. They prefer to be able to do all the testing and debugging inside Visual Studio.

Production Ready ?

Nope, not yet! Only 3 people in Stadia are working on this kind of project, and they consider it to be R&D level so far.

So Stadia may not be able to use what they have developed to massively increase their games library any time soon, but they are on the way to make things easier to port with minimal modifications.

Most of that work does not seem to be FOSS, so we may have to assume it’s going to be proprietary tech for now.