Getting Steam to run with proprietary nVidia.

According to this earlier posting, I had switched my Debian / Stretch, Debian 9 -based computer named ‘Plato’ from the open-source ‘Nouveau’ drivers, which are delivered via ‘Mesa’ packages, to the ‘proprietary nVidia drivers’, because the latter offer more power, in several ways.

But then one question which we’d want an answer to, is how to get “Steam” to run. Just from the Linux package manager, the available games are slim picking, and through a Steam membership, we can buy Linux-versions of at least some powerful games, meaning, to pay for with money.

But, when I tried to launch Steam naively, which used to launch, I only got a message-box which said, that Steam could not find the 32-bit version of ‘libGL.so’ – and then Steam died. This temporary result ‘makes sense’, because I had only installed the default, 64-bit libraries, that go with the proprietary packages. Steam is a 32-bit application by default, and I have a multi-arch setup, as a prerequisite.

And so my next project became, to create a 32-bit as well as the existing, 64-bit interface to the rendering system.

The steps that I took assume, that I had previously chosen to install the ‘GLVND’ version of the GLX binaries, and unless the reader has done same, the following recipe will be incorrect. Only, the ‘GLVND’ packages which I initially installed, are not listed in the posting linked to above; they belonged to the suggested packages, which I wrote I had written down on paper, and then added to the command-line, which transformed my graphics system.

When I installed the additional, 32-bit libraries, I did get a disturbing error message, but my box still runs.

Continue reading Getting Steam to run with proprietary nVidia.

I’m impressed with the Mesa drivers.

Before we install Linux on our computers, we usually try to make sure that we either have an NVIDIA or an AMD / Radeon  GPU  – the graphics chip-set – so that we can use either the proprietary NVIDIA drivers designed by their company to run under Linux, or so that we can use the proprietary ‘fglrx’ drivers provided by AMD, or so that we can use the ‘Mesa‘ drivers, which are open-source, and which are designed by Linux specialists. Because the proprietary drivers only cover one out of the available families of chip-sets, this means that after we have installed Linux, our choice boils down to a choice between either proprietary or Mesa drivers.

I think that the main advantage of the proprietary drivers remains, that they will offer our computers the highest version of OpenGL possible from the hardware – which could go up to 4.5 ! But obviously, there are also advantages to using Mesa , one of which is the fact that to install those doesn’t install a ‘blob’ – an opaque piece of binary code which nobody can analyze. Another is the fact that the Mesa drivers will provide ‘VDPAU‘, which the ‘fglrx’ drivers fail to implement. This last detail has to do with the hardware-accelerated playback of 2D video-streams, that have been compressed with one out of a very short list of Codecs.

But I would add to the possible reasons for choosing Mesa, the fact that its stated OpenGL version-number does not set a real limit, on what the graphics-chip-set can do. Officially, Mesa offers OpenGL 3.0 , and this could make it look at the surface, as though its implementation of OpenGL is somewhat lacking, as a trade-off against its other benefits.

One way in which ‘OpenGL’ seems to differ from its competitor in real-life: ‘DirectX’, is in the system by which certain DirectX drivers and hardware offer a numeric compute-level, and where if that compute-level has been achieved, the game-designer can count on a specific set of features being implemented. What seems to happen with OpenGL instead, is that 3.0 must first be satisfied. And if it is, the 3D application next checks individually, whether the OpenGL system available, offers specific OpenGL extensions by name. If the application is very-well-written, it will test for the existence of every extension it needs, before giving the command to load that extension. But in certain cases, a failure to test this can lead to the graphics card crashing, because the graphics card itself may not have the extension requested.

As an example of what I mean, my KDE / Plasma compositor settings, allow me to choose ‘OpenGL 3.1′ as an available back-end, and when I select it, it works, in spite of my Mesa drivers ‘only’ achieving 3.0 . I think that if the drivers had been stated to be 3.1 , then this could actually mean they lose backward-compatibility with 3.0 , while in fact they preserve that backward-compatibility as much as possible.

screenshot_20171127_185831

screenshot_20171127_185939

Continue reading I’m impressed with the Mesa drivers.

There is a bug in the Wayland Compositor, under Debian Stretch.

One of the facts which I have written about before, is that modern desktop managers will use compositing – i.e. will use hardware-acceleration – to render desktop effects, specifically, when we are only running regular, 2D applications with a GUI. This feature exists with the old KDE 4, under Debian / Jessie, as well as with the new Plasma 5, under Debian / Stretch.

Under Debian / Jessie, this feature is extremely stable. Under Debian / Stretch, it is not yet so.

What will happen under Debian / Stretch, as far as I can make out, is that if an attempt has been made to disable compositing, instead of this succeeding, the desktop-session becomes corrupted, in that black rectangles will display, when we simply open multiple windows / dialogs. AFAICT, This can only be fixed, by rebooting / starting a new user-session.

I became aware of this, when running Steam-based games on the computer I name ‘Plato’. When games run that are heavy on OpenGL / Hardware-Rendering, it’s normal for the game-platform to try to switch compositing off, because often, the hardware-rendering of the game is not compatible with the desktop-compositing. After I have finished my session with Steam, the rendering errors in my desktop manager become noticeable, and Steam does not gain the permissions, to install any system software.

I do not blame this on Steam per se, because I can reproduce this problem by just clicking <Shift>+<Alt>+F12, which used to be the key-combination under KDE 4, that toggled desktop compositing on and off at will. Within seconds, under Plasma 5, this key-combination will also cause the malfunction.

(Updated 12/03/2017 : )

Now, there is a simplistic workaround for me:

 

Continue reading There is a bug in the Wayland Compositor, under Debian Stretch.

How The Use Of Steam Can Hinder Efficiency.

There exists a concept in Thermodynamics, which describes theoretical limits in the efficiency of all possible heat-engines. This principle states, that if we have a heat-source and a heat-sink, each has an absolute temperature. The ratio between these temperatures defines the highest-possible output of free energy from a heat-engine, as well as the lowest-possible consumption of free energy by a refrigeration-device.

The principle is based on the axiomatic assumption, that there exist no perpetual-motion machines, which simply convert ambient heat into free energy. If we could connect a heat-engine to an air-conditioner, and if these limits could be exceeded, we would have such a perpetual-motion machine.

This also explains why in practice, air-conditioners, refrigerators and heat-pumps can transfer heat from a colder source to a warmer sink, with the energy in heat far-exceeding the electricity consumed. They are all examples in which the ratio of absolute temperatures is close to 1.0 . Actually, what matters is the ratio of the temperatures of the working-fluid in each case, which is actually more oblique than the ratio for air temperatures, because heat-exchangers are never perfectly efficient. And the working-fluids used tend to be similar, because the temperatures at which those systems are designed to work, are also similar.

This also implies that if we wanted to build a heat-engine that uses small temperature-differences to generate electricity, large reserves of heat would be needed as a source, and sent to the sink, before even small amounts of electricity result – which might sometimes be available – but which constrains the system, regardless of what type of heat-engine is used.


Well, in Industrial Power Generation, the temperatures which the heat-source can be run at, depend firstly on what type of fuel is burning, but also depend on the range of temperatures at which water will boil. At 1 atmosphere of pressure, water only boils at 100⁰C, which is also 373K, while the external temperature tends to be around 273-300K .

Actually, by keeping the water boiling at much higher pressures, its boiling-point can also be increased. But it is generally not boosted beyond 200⁰C , which corresponds to about 473K . And so, according to basic principles, no power station based on water and steam, can be more than 50% efficient.

(Edit 05/12/2017 : Additionally, my late father, who was a professional Engineer, used to tell me, that something prevents a steam turbine from being more than 50% efficient. But, this is not a subject I know about, even though it would additionally limit the maximum efficiency of steam-turbine-based power-stations, to approximately 25%. )

In theory, if we could operate our heat-engine at 1000K, and its heat-sink still at 300K, we could achieve efficiencies closer to 70%. Mind you, that that point our heat-source might resemble a lightbulb, more than what we are used to, but this would still obey the rules of Thermodynamics.

My only point being, that the use of water, and its associated boiling-points, is an arbitrary decision. There is no magical reason why we must use it. We could use vaporous sodium if we knew how to work with it safely.

If one breaks out, a sodium-fire is a nasty hazard, much more dangerous in its nature than wood or oil-fires already are.

Dirk

Continue reading How The Use Of Steam Can Hinder Efficiency.