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

What experience do I claim to have with this?

Well, I’ve just bought a computer-game called ‘Quern‘, thereby obtaining the Linux / OpenGL -compatible version from Steam, and it runs on one of my computers, while not running on the other.

More specifically, while the two computers that I can compare are both using Mesa drivers, one was built in 2011 and contains an NVIDIA chip-set, while the other was built in 2013, and contains an AMD / Radeon chip-set. The computer that was built in 2013 actually runs an older version of Linux, that being Debian / Jessie, while the other happens to be running a newer version of Linux, that being Debian / Stretch. The package repositories of the older Linux system, also contain the older Mesa drivers.

But this software runs on the newer computer, which is using the older Mesa drivers, because the newer hardware offers extensions which the older hardware did not offer.

The types of extensions that are involved, are the most part of what the ‘glxinfo’ command prints out, or also, what we can see by running the GUI-program ‘KInfoCenter’. These extensions form reams and reams of C macros, each of which equate a cryptic name with an integer.

Interestingly enough, we might also want to give credit to ‘Steam’, for making this wonderful game available to Linux users. But on the technical side, ‘Steam’ is a front-end for OpenGL, as well as a game-engine, which certain games can easily be adapted to.

What tends to happen is that varying hardware-capabilities are detected by the drivers, made available to Steam through the OpenGL API, and finally made available to Devs by Steam, so that the Devs can build games.

What has both made and broken my ability to run this game was not, how recent my Linux version was, nor, which manufacturer built the graphics-card, but how recent the graphics-card was.

Dirk

 

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>