GLES v1 support was initially disabled as it was a belief among some of
the editors and contributors that GLES v1, being an older API, was not
required by any packages or games, or if games needed it, Steam would
provide GLES v1. This commit serves as prove that the contradiction is
correct. As for packages, pretty much all GLES packages use GLES v2/v3.
Games on the other hand can use GLES v1. Steam does not supply GLES v1
and this can be confirmed via a find command in ~/.local/share/Steam.
There is the bootstrap tarball which actually does contain libGLESv1_CM
in /libglvnd-1.7.0/build/DESTDIR/usr/lib. The Steam runtimes (normal
client runtime: steamrt64; Soldier and Sniper) don't package GLES v1 in
any way besides what is provided by Wine as DLLs. So if a Linux native
game needs GLES v1, it's up to the system to provide the capabilities.
Thanks @renodr for bringing this to my attention.
This follows what we are doing in BLFS now, though in that case it was
required because we were removing the static library and CMake was still
referencing it in files that it installed.
It caused issues over there with libheif, and even though that package
isn't in GLFS, let's fix it over here as well for consistency.
Fixes#354
This ports much of https://github.com/glfs-book/slfs/pull/469, though
some notable changes were made:
- Commands the reader might wish to run (including examples) are placed
on their own lines where possible.
- Tweak the recently added notes at the end.
8. Graphics APIs
9. Graphics Drivers, Preliminaries
10. Graphics Drivers, NVIDIA
11. Graphics Drivers, Mesa
This was done to set up the groundwork for including multiple NVIDIA
versions to support more NVIDIA GPUs. r590 killed off support for
pre-turing GPUs, meaning anything before GTX 16xx is effectively dead
unless Mesa's nouveau is used. This is a problem because pre-turing GPUs
are everywhere and are still recommended as beginner GPUs. Thus, there's
cause to have older NVIDIA versions, as well as new ones.
The main plan is to split up the NVIDIA chapter somehow. This can be
done via dummies. There are a few issues to bear:
1. To create separate pages for different NVIDIA versions will create a
lot of duplicate work. This can be resolved via entities.
2. Including multiple NVIDIA versions in a single page will result in
the NVIDIA page bolstering in size. Already, the NVIDIA page in the
book is the longest of them all for no good reason beyond the
complexity of installation. This is a result of our manual
kernel installation approach. The driver library approach has been
made much shorter already.
3. CUDA follows NVIDIA in terms of GPU and driver support. Meaning new
CUDA versions will require an at-least NVIDIA version, often that of
a beta version. This causes issues since newer CUDA versions can't be
used unless the driver is upgraded to the minimum. Thus, multiple
CUDA versions must be provided.
4. Because of issue 3, this causes issues for SLFS and conciseness. As
such, the plan is to move CUDA to this book. With everything,
separate pages for separate versions will be the best approach; an
ugly one, but our best shot.
Entities will be our best friend here.
The development version of BLFS recently got GNOME 49. I don't think
anything uses the gnome.ent file over here, but just in case we should
sync it anyway.
Apparently, the previous instructions cause the CMake modules to be
malformed in some way. I don't have time to test this at the moment but
I will look into how to build just the libs and install correct CMake
modules later.
