Steam Survey For July 2016: Linux +0.02%

[SaucyJack]

I am not sure what you mean.

Oh come on, now you're just trolling.

Ok, in the case you're just that oblivious (or stupid), a CPU has registers. There are twice as many registers available to 64-bit applications as opposed to a 32-bit application. The performance improvement of 64-bit over 32-bit software is often surprising low considering, but still notable. In some cases it can lead to drastic performance increases. There was even a benchmark ran here on phoronix comparing 32-bit vs 64-bit.

[starshipeleven]

Every game I've bought in the last year was 64 bit, or had a 32 bit version along side a 64 bit version. So I have no idea where you're getting this stuff.

I meant that games that are 32bit now will not be magically updated to 64bit, nor will go away.
Admittedly this is more true for windows land.

Most of my games are too either 64bit only or both archs are available.

[SaucyJack]

Why do you expect 64-bit x86 code to perform much better than 32-bit? In my opinion, given a particular transistor budget the best theoretical CPU for x86 code would run 32-bit x86 code faster than 64-bit x86 code. It is therefore quite surprising that actual CPUs from AMD/Intel perform about the same in 32-bit mode than in 64-bit mode.

----

An x86 CPU needs to look at an additional byte for an AMD64 instruction to get access to registers R8-R15. The additional byte might in some cases cause the CPU to decode 1 instruction less per clock.

----

The capacity of an x86 CPU in terms of register renaming is the same for 32-bit code and 64-bit code. This makes the fact that 32-bit code performs close to 64-bit code less surprising. Along the same note, an x86 CPU has many features/constants/limits common to 32-bit and 64-bit which are causing 32-bit and 64-bit code to perform about the same.

With current x86 CPU architectures, a "drastic" performance increase of 64-bit code over 32-bit code might indicate the application isn't optimized well.

That's a big wall of bullshit.

[Kano]

There is an issue in Debian and derivatives, where you cannot have two mesa libraries of different architectures because "hell if I know", so the 64bit one is screwed up or removed when you install Steam (so if you want to uninstall it you mus also reinstall such package/s).

Incorrect, libs are using the same changelog for any arch, the rest is in different subfolders. Therefore they can be installed in parallel - what is impossible is to install two packages containing executables which are different but placed at the same position. Installing mesa-utils:i386 will remove the amd64 package for example. Don't say something about you don't know anything!

[Passso]

As I said, that's totally irrelevant as it is NOT a statistically significant number nor a group of people selected in a way that ensures you aren't gating answers without knowing it.

I know, but that's the best I can provide.

[starshipeleven]

Incorrect, libs are using the same changelog for any arch, the rest is in different subfolders. Therefore they can be installed in parallel - what is impossible is to install two packages containing executables which are different but placed at the same position. Installing mesa-utils:i386 will remove the amd64 package for example. Don't say something about you don't know anything!

Read this plx and stfu https://www.phoronix.com/forums/foru...755#post888755

Anyway, you can have libraries in the same place too, it comes down to how it is made the distro. Multiarch was implemented later and distros implement it their own way (some rename the libs, some place them in subfolders, and so on). What matters here is that Debian is NOT fully multiarch-safe, while most other distros are.

Meanwhile, on OpenSUSE i have the full Mesa stack in both 32 and 64 bit (because Steam) and there is NO ISSUE AT ALL. LIKE IT SHOULD FUCKING BE.

sudo zypper search mesa
Loading repository data...
Reading installed packages...

S | Name                          | Summary                                                      | Type    
--+-------------------------------+--------------------------------------------------------------+-----------
  | DirectFB-Mesa                 | Mesa backend of Graphics Library for Framebuffer Devices     | package  
i | Mesa                          | System for rendering interactive 3-D graphics                | package  
  | Mesa                          | System for rendering interactive 3-D graphics                | srcpackage
i | Mesa-32bit                    | System for rendering interactive 3-D graphics                | package  
  | Mesa-demo                     | Mesa demo programs for the OpenGL stack                      | package  
  | Mesa-demo-x                   | GLX-based demos                                              | package  
  | Mesa-devel                    | Libraries, includes and more to develop Mesa applications    | package  
  | Mesa-dri-devel                | Development files for the DRI API                            | package  
i | Mesa-libEGL-devel             | Development files for the EGL API                            | package  
  | Mesa-libEGL-devel-32bit       | Development files for the EGL API                            | package  
i | Mesa-libEGL1                  | Free implementation of the EGL API                           | package  
i | Mesa-libEGL1-32bit            | Free implementation of the EGL API                           | package  
i | Mesa-libGL-devel              | GL/GLX development files of the OpenGL API                   | package  
  | Mesa-libGL-devel-32bit        | GL/GLX development files of the OpenGL API                   | package  
i | Mesa-libGL1                   | The GL/GLX runtime of the Mesa 3D graphics library           | package  
i | Mesa-libGL1-32bit             | The GL/GLX runtime of the Mesa 3D graphics library           | package  
  | Mesa-libGLESv1_CM-devel       | Development files for the OpenGL ES 1.x API                  | package  
  | Mesa-libGLESv1_CM-devel-32bit | Development files for the OpenGL ES 1.x API                  | package  
  | Mesa-libGLESv1_CM1            | Free implementation of the OpenGL|ES 1.x Common Profile API  | package  
  | Mesa-libGLESv1_CM1-32bit      | Free implementation of the OpenGL|ES 1.x Common Profile API  | package  
i | Mesa-libGLESv2-2              | Free implementation of the OpenGL|ES 2.x API                 | package  
  | Mesa-libGLESv2-2-32bit        | Free implementation of the OpenGL|ES 2.x API                 | package  
  | Mesa-libGLESv2-devel          | Development files for the OpenGL ES 2.x API                  | package  
  | Mesa-libGLESv2-devel-32bit    | Development files for the OpenGL ES 2.x API                  | package  
  | Mesa-libGLESv3-devel          | Development files for the OpenGL ES 3.x API                  | package  
  | Mesa-libd3d                   | Mesa Direct3D9 state tracker                                 | package  
  | Mesa-libd3d-32bit             | Mesa Direct3D9 state tracker                                 | package  
  | Mesa-libd3d-devel             | Mesa Direct3D9 state tracker development package             | package  
  | Mesa-libd3d-devel-32bit       | Mesa Direct3D9 state tracker development package             | package  
  | Mesa-libglapi-devel           | Development files for the free implementation of the GL API  | package  
  | Mesa-libglapi-devel-32bit     | Development files for the free implementation of the GL API  | package  
i | Mesa-libglapi0                | Free implementation of the GL API                            | package  
i | Mesa-libglapi0-32bit          | Free implementation of the GL API                            | package  
  | libOSMesa-devel               | Development files for the Mesa Offscreen Rendering extension | package  
  | libOSMesa-devel-32bit         | Development files for the Mesa Offscreen Rendering extension | package  
  | libOSMesa9                    | Mesa Off-screen rendering extension                          | package  
  | libOSMesa9-32bit              | Mesa Off-screen rendering extension                          | package

[Passso]

Meanwhile, on OpenSUSE i have the full Mesa stack in both 32 and 64 bit (because Steam) and there is NO ISSUE AT ALL. LIKE IT SHOULD FUCKING BE.

+1, this is why Steam installation under Opensuse is as simple as 1-click, compared to Ubuntu and derivates.

[Kano]

starshipeleven

The Wiki page is not uptodate. First of all I wrote a script to install Steam on whezzy at day 1 of Steam for Linux and it worked for most of the games. The first big one that did not work was Payday 2 which was build against a too new glibc. Btw. Kanotix has Steam preinstalled on Special iso images (together with binary drivers and updated mesa for Intel) since march 2013. You can be sure I know Debian.

[starshipeleven]

starshipelevenThe Wiki page is not uptodate. First of all I wrote a script to install Steam on whezzy at day 1 of Steam for Linux and it worked for most of the games. The first big one that did not work was Payday 2 which was build against a too new glibc. Btw. Kanotix has Steam preinstalled on Special iso images (together with binary drivers and updated mesa for Intel) since march 2013. You can be sure I know Debian.

The wiki page is 100% accurate, as I experienced THE EXACT same issue they mentioned on Debian Jessie, less than 2 months ago.
First of all the issue is not about installing Steam as that is handled by the Steam thingy itself, but about removing Steam and all 32bit libraries that came with it (I know that it is strange but sometimes people may want to dump Steam and its deps because of legit reasons).
It will leave you without openGL libraries (so no more OpenGL acceleration) unless you reinstall the 64bit version of them (but this is NOT stated anywhere during the uninstallation process of Steam or when I apt-get remove the useless 32bit libs).
I've been using Debian for like the last few decades, on PCs, servers and semi-embedded systems, so you can be sure I know Debian.