It Looks Like A Steam 64-Bit Client Could Finally Be Near

[cl333r]

...The other reason for keeping 32-bit is that you can run old 16-bit applications.

That's not a reason to keep 32 bit support for anyone sane.

[jukk]

That's not a reason to keep 32 bit support for anyone sane.

I agree. That is what I meant. Not many reasons anymore.

[M@yeulC]

Shouldn't have any impact on 64bit builds for games, they were able to be shipped prior to this and there are quite a few of them. That's just a developer choice.

As far as the Steam controller, what issues? I have one and have had no issues with mine in Linux, Android or Windows (some problems on my Mac but it's company owned... probably some security restrictions there).

Sure, but not every game that could is shipping an x64 elf.

I've hit some issues with the steam controller and action layers (they are not respected... systematically, as they sometimes work if I reload the configuration) and activators that gets ignores. This makes it a hassle to create proper configurations, and makes me wonder if they have proper unit tests. The mouse emulation tends to be choppy at times (maybe especially together with activators?). Finally, the Steam Controller isn't working anymore when Steam hasn't been started; it has been the case for a while.

yoshi314 : keep in mind that you'd still need a few 32 bit libraries. Quoting plagman from the above github issue:

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.

The other reason for keeping 32-bit is that you can run old 16-bit applications.

Don't 16 bit apps still run in 64 bit wine prefixes? I must admit I didn't try it.

[AndyChow]

I thought the steam client was just an "installer", so 32-bit or 64-bit shouldn't matter, and says nothing about whatever games run once launched from it. The only reason I can imagine to go 64-bit is to remove the multilib dependencies.

More urgently, maybe there is an option, but if you're downloading games, and launch one, the client stops downloading the other games or updates. Which makes no sense, since a lot of new games are 50GB+ files, which take a while to download, but takes at most 1%CPU and 0%GPU resources,

I've had no problems at all with the steam controller, except that it's really hard to use in some games. Like turning fast you need to swipe over and over, or turn slowly. Overgrowth is a game that doesn't work well with the steam controller.

[FireBurn]

More urgently, maybe there is an option, but if you're downloading games, and launch one, the client stops downloading the other games or updates. Which makes no sense, since a lot of new games are 50GB+ files, which take a while to download, but takes at most 1%CPU and 0%GPU resources,

There's a setting for that already - the reason that does it, is some network games can be adversely affected and if you've a fast connection like myself the disk i/o can make the game play like crap

[Jabberwocky]

That's not a reason to keep 32 bit support for anyone sane.

People are attracted to the things they can't have, that said I have almost 1000 steam games, but still play earth siege 2 (16bit) from time to time. Unfortunately it does not run in DosBOX (yet?) so I usually resort to Win95 in a VM which is rather time consuming. By this point you should notice that I am not a sane person!

[Adarion]

OMG, like hell froze over.
I'm all for keeping 32bit compatibility, but a system that is targeting _gaming_ is very likely to deal with a lof of 64bit requirements anyway. A lot of games come as 64bit binaries, for some just definitely need to address a large amount of RAM.
Maybe this will finally lead to better compatibility with non-stock-Debian/*buntu distributions? I remember it was runnig okay on my Gentoo for months, and then, after a mesa / kernel / ...AMD-driver stack update it would not start, only throw lots of library errors. Deleting bundeled stuff partiall helped to shift error messages, but hardly ever got it to run again. I had little time for gaming anyway and still had DRM-free-hib/gog games (that would usually run fine), so I did not try for some time.
But this might be the needed step in the right direction.

[nanonyme]

OMG, like hell froze over.
I'm all for keeping 32bit compatibility, but a system that is targeting _gaming_ is very likely to deal with a lof of 64bit requirements anyway. A lot of games come as 64bit binaries, for some just definitely need to address a large amount of RAM.
Maybe this will finally lead to better compatibility with non-stock-Debian/*buntu distributions? I remember it was runnig okay on my Gentoo for months, and then, after a mesa / kernel / ...AMD-driver stack update it would not start, only throw lots of library errors. Deleting bundeled stuff partiall helped to shift error messages, but hardly ever got it to run again. I had little time for gaming anyway and still had DRM-free-hib/gog games (that would usually run fine), so I did not try for some time.
But this might be the needed step in the right direction.

Afaik majority of sold games are still 32bit because managements optimize for revenue

[nanonyme]

Sure, but not every game that could is shipping an x64 elf.

I've hit some issues with the steam controller and action layers (they are not respected... systematically, as they sometimes work if I reload the configuration) and activators that gets ignores. This makes it a hassle to create proper configurations, and makes me wonder if they have proper unit tests. The mouse emulation tends to be choppy at times (maybe especially together with activators?). Finally, the Steam Controller isn't working anymore when Steam hasn't been started; it has been the case for a while.

yoshi314 : keep in mind that you'd still need a few 32 bit libraries. Quoting plagman from the above github issue:





Don't 16 bit apps still run in 64 bit wine prefixes? I must admit I didn't try it.

You need a CPU emulator (eg Qemu) to run 16bit software when CPU is running in 64bit mode. Whether it is or not depends on which kernel you have

[Luke_Wolf]

There is little advantage to having 64-bit executable instead of 32-bit one for the Steam client. It's memory consumption will probably never exceed the 32-bit address space limit (4 GiB limit). Its current address space consumption (VIRT in htop) on my machine is 685MiB while its current memory consumption is 163MiB. Arguably, 685 MiB is close to 4GiB, but I think this poses no problem.

The Steam client is launching other executables via fork()+exec() and those other executables can freely be 32-bit, 64-bit or shell scripts.

I do not have internal information about the planned evolution of the Steam client, and it may be the case they plan some features which will grow the address space consumption of the Steam client in the future - in which case providing 64-bit executable makes sense. On the other hand, optimization can shrink those 685MiB to a lower value.

This is exactly why Steam and other general applications should not be 32-bit. I'm not really sure how the Linux kernel 32-bit multilib handles this (The alternative is rather convoluted and would have a performance hit I'm sure Torvalds wouldn't like because the kernel part would be real but then you'd have an address translation going on for everything above it) but on Windows the 32-bit multilib considers only the lowest 4GB (starting from memory location 1) for 32-bit applications, which along with allowing static memory addressing in 32-bit mode means that everything that's 32-bits is sharing the same extremely limited space which makes it incredibly easy for 32-bit applications to stomp all over one another and cause them to run out of memory and crash. Skype was historically particularly nasty about causing crashes in games.

Instead if a game must be 32-bit for legacy reasons, then if everything else is 64-bit, this game can have the lower 32-bits to itself and the kernel, which will make the game much much happier, because 4GB is a tight space to work within, meanwhile 16GB of RAM is the new normal (For gaming PCs) so the extra memory cost is a non-problem.