Updated steam runtime question from #4768

[kisak-valve]

Posted by @ikeydoherty on #4768.

@kisak-valve mostly thinking aloud here, but.. It occurs to me that my biggest issue with the Steam runtime has nothing to do with it not being the "native" runtime. It's just one that is generic and old.

What if there were a way for Steam to provide its own optimized runtime, and ABI compatibility? It's something I've been mulling over for a while, and would be better than the current system and various hacks around it (mine included).

Would Valve be open to viewing and testing such a system? Created by yours truly, of course. Additionally, how important it is that the runtime is managed & updated as the current user. Is polkit a viable thing here? (Keep in mind that the rules could permit admin but without password.)

The way I see it is that Valve is bending over backwards trying to keep this runtime system together, and there isn't a viable cohesive measure in place between all the differing distros. What if you leave that stuff for us distro-heads to work out, and we present you with something that could end the issues once and for all? And arguably boost the Linux gaming performance.

Looking forward to your response.

[kisak-valve]

Hello @ikeydoherty, so it is clear, I am a moderator for this issue tracker. We'll need to wait and see if a Valve dev wishes to comment on this topic.

[ikeydoherty]

@kisak-valve yeah suspected as much - thanks for moving it across.

[mirh]

I hope they may also be able to comment on the AppImage/Flatpak/Snappy affair.

[ikeydoherty]

Alright so long story short, Solus just adopted flatpak

Effectively, we're going to produce a gaming specific runtime that is created with every intention of being entirely ABI compatible for the Steam runtime. The difference being is that it will replace the runtime used by Steam currently.

It will leverage the Solus work on build machinery to provide a highly optimized runtime and SDK, so that Steam can then be provided as a flatpak depending on this repo (Which we'll also set up/host on on the Solus infrastructure).

Due to the isolation from the host, any Linux user will be able to benefit from the runtime, have no ABI issues, and get all the juice out that they need. Additionally, game developers will be able to leverage the SDK for this runtime to build against and test.

Entirely up to the Valve crew if they're interested in this, but it's the direction Solus is going to take and we're open to working with others, and taking orders from Valve on the specification & requirements here. :)

[IronJaeger]

(...Entirely up to the Valve crew if they're interested in this, but it's the direction Solus is going to take and we're open to working with others, and taking orders from Valve on the specification & requirements here.) It's a lifetime opportunity to give Ikey, the irish benevolent dictator ORDERS!! That's an opportunity not to miss, Valve! #just_DO_IT xD

[Plagman]

How are you planning to access external libraries like graphics drivers?

[ikeydoherty]

Currently I'm pursuing multiple avenues. Flatpak Extensions, bind mounting select host libs, glvnd-like approach, etc, to find the one that works the best. Obviously the driver situation (chiefly NVIDIA drivers) are very important to Solus, because there wouldn't be an awful lot of point in starting this if we didn't want to enable the host side drivers :)

Also happy to see what you might've had under consideration while I'm off doing this

[ikeydoherty]

Also to clarify for those visiting this issue, I am in no way asking for a commitment from Valve at this point. The aim here is to raise awareness of an impending effort, gather initial thoughts before we kick off, and to keep Valve abreast of developments external to their platform. The aim of course is to then put this into practice, present a working demonstration and go from there.

[Plagman]

Yes it's definitely interesting, thanks for the data. We've been looking at underlying Flatpak technologies but there are some things to work out with accessing external libraries.

[swick]

You might also want to think about per game flatpak'ing instead. This would allow you to bind mount a specific GL driver version for a game. You could make daily mesa builds and if there are regressions you can just choose an older version for the regressed games. Also, if you ever wanted to officially support wine you could do the same thing.

[mrmcq2u]

@swick Definitely think the idea of providing flatpak for steam runtime is great, don't think it makes sense for distributing games though. Steam is responsible for platforms other than Linux.

[ShalokShalom]

Steam is responsible for a lot of things and they ignore them, so?

[ikeydoherty]

K let's not drive the thread quality down, thanks.