Valve Planning To Carry Mesa GL Thread Feature On SteamOS, Per-Game Features

[cj.wijtmans]

Steam having a 64bit client has nothing to do with its ability to launch 32 bit games. But perhaps they should make a dependency system that automatically downloads required libs that are missing from the steam-runtime. Meaning you dont launch 32bit games you wont pull 32 bit libs and check if the kernel even supports 32 bit before launching. (how do you disable 32bit in the kernel anyway? i know you can disable 16bit or does vsyscall emulation also disable 32bit? i dont think it does).

[cb88]

Steam having a 64bit client has nothing to do with its ability to launch 32 bit games. But perhaps they should make a dependency system that automatically downloads required libs that are missing from the steam-runtime. Meaning you dont launch 32bit games you wont pull 32 bit libs and check if the kernel even supports 32 bit before launching. (how do you disable 32bit in the kernel anyway? i know you can disable 16bit or does vsyscall emulation also disable 32bit? i dont think it does).

You just disable loading 32bit binary support... its literally an option in the kernel config. Kinda pointless to enable and disable that sort of stuff though unless you have very specific reasons.

[starshipeleven]

That's a circular reasoning. 32 bits should be dropped ASAP (and I say this while regularly playing Steam games on my laptop, which has a 32 bits only Atom).
Of course, having a way to play old 32 bits game would be nice, but that's something I'm prepared to do without.
The major blocker will probably be middleware, however.

Let's make a difference between a whole OS running in 32bit vs a whole OS running in 64bit mode + some applications that don't really need RAM still in 32bit mode.

Applications can stay 32bit and it's not going to hurt anyone as the biggest limitation is that they won't be able to use more than 3 GiB of ram for themselves (which is not going to happen for many programs anyway), the OS and other applications that do like RAM (browsers for example) have to go 64bit, period.

[Veerappan]

That's a circular reasoning. 32 bits should be dropped ASAP (and I say this while regularly playing Steam games on my laptop, which has a 32 bits only Atom).
Of course, having a way to play old 32 bits game would be nice, but that's something I'm prepared to do without.
The major blocker will probably be middleware, however.

On the topic of glthread, I am all for its inclusion (if the code quality is good enough). And if the current code causes a lot of regressions, a whilelist sounds sensible. Maybe the proper solution is to create a new OpenGL extension to enable or disable it?
I do not see this as extremely game-specific. That's not hand-optimizing shaders for some games. But it would be nice if it could be made so that it works reliably with every game.

Why would you need a simple browser-based GUI to be a 64-bit application (it doesn't need the increased address space or additional registers... I can see an argument for the extra disk space used by installing 32-bit gui libraries, but I don't see it being that convincing)? Steam as-is can launch both 64 and 32-bit games, and shipping a 64-bit client is just additional overhead that isn't really worth the effort, in my opinion.

And yes, I'm saying this as someone whose main desktop's linux partition is a 60GB portion of a 120GB SSD (with a larger spinning disk for data).. It's just not worth the hassle. Multi-lib is here, it's a thing, it works fine, and it's not going away anytime soon.

[tegs]

The problem with Valve is that they are not releasing 64 bit verison of Steam which is unacceptable in 2017... I built kernel without 32 bit support and im not going to waste my disk space by installing multilib(32 bit versions of drivers and other libs)...

I'm willing to give Solus a try in the near future since I like how they handle Steam: https://www.phoronix.com/scan.php?pa...am-Runtime-ABI

[arzeth]

The problem with Valve is that they are not releasing 64 bit verison of Steam which is unacceptable in 2017...

I thought the same until I saw the last comment here (which is from Valve's Plagman): https://github.com/ValveSoftware/ste...nux/issues/179

We will not drop support for the many games that have shipped on Steam with only 32-bit builds, so Steam will continue to deploy a 32-bit execution environment. To that end, it will continue to need some basic 32-bit support from the host distribution (a 32-bit glibc, ELF loader, and OpenGL driver library).

Whether the Steam client graphical interface component itself gets ported to 64-bit is a different question altogether, and is largely irrelevant as the need for the 32-bit execution environment would still be there because of the many 32-bit games to support.

As far as I understood, the problem is that (most of) 32-bit only games bundle their own libsteam.so/libsteam_api.so/libSteamworksNative.so/etc, and these libraries require the 32-bit build of Steam. Or maybe I misunderstood...

I built kernel without 32 bit support and im not going to waste my disk space by installing multilib(32 bit versions of drivers and other libs)...

I use Arch Linux (so there's only /usr/lib32 for 32-bit libraries) and I have installed all (217!) lib32-* packages that games would ever need (i.e. I didn't install lib32-{clang,wxgtk,tcl,libdaemon,etc...} ), my FS is ext4:

$ du -sh /usr/lib32
641M    /usr/lib32

That's a size of an average video in modern games.
Even when I had had to use an 8GB Kingston USB flash drive (because my 9-year old WD HDD 80 GB IDE had got broken because of a very I/O intensive downloading of the Bitcoin blockchain with bitcoin-qt) in 2014, I had a free space (thanks to btrfs's compress-force=zlib) to install some of lib32-* packages so that I could play StarCraft 1 (of course, I replaced its 1115MB of videos with two special 30KB .mpq files).
So if you are concerned about a free space, then use btrfs with a mount option compress-force=zlib. ZFS supports compression too, but other filesystems don't support it.

[pal666]

That's a circular reasoning. 32 bits should be dropped ASAP

there was intel processor without (backwards-compatible) 32bit support. everyone uses amd64 which was carefully designed with 32 bit support. guess why

Of course, having a way to play old 32 bits game would be nice, but that's something I'm prepared to do without.

good for you then, you can switch to risc-v

[pal666]

As far as I understood, the problem is that (most of) 32-bit only games bundle their own libsteam.so/libsteam_api.so/libSteamworksNative.so/etc, and these libraries require the 32-bit build of Steam. Or maybe I misunderstood...

you misunderstood 32-bit games require 32-bit support from os, that is all. steam is not going to drop support for them, so steam is not going to work on os without 32-bit support

[TingPing]

Why do this and not integrate wine into steam? You come to the same ethical choice.

It is just impossible to support.

[mulenmar]

I'm all for dropping 32-bit x86 support, with the limited registers and memory access range, personally. Pollish off the accuracy of qemu, then use the virtualization extensions modern CPUs have anyway to run a 32-bit compatibility OS for whatever programs can't be ported or migrated-from (essentally what Apple did for the PowerPC->Intel switchover). But then, given the powerswitch-independent, higher-privlege-than-the-OS, blackbox backdoors in modern Intel and AMD cpus, everyone should be migrating away from and dropping the architecture entirely. That's about as likely to happen as the discussion sticking to the topic, of course. :P

Frankly, I think this out-of-tree idea is a bad, though not terrible, idea. This "white-listing" and special treatment on Windows has done little but mask the bugs of games that the developers didn't have time to fix themselves; the protocol of ensuring the open-source drivers work *correctly* and to the specification forces cross-platform developers to do things right on their end as well, leading to better software and more-stable games in the long-term, on all platforms.