Difference between pages "Package:Eselect (OpenGL)" and "News:New OpenGL management in Funtoo"

(Difference between pages)
(update on config issue)
 
(explanation of the new system)
 
Line 1: Line 1:
{{Ebuild
+
{{News
|Summary=A Gentoo/Funtoo utility that allows the active OpenGL implementation on a system to be switched between a variety of installed options.
+
|Summary=Funtoo is switching to an improved system for managing multiple OpenGL providers (Mesa/Xorg, AMD and nVidia). The update may involve blockers and file collisions.
|CatPkg=app-admin/eselect-opengl
+
|News Format=Extended
|Maintainer=
+
|News Category=Packages
 +
|Author=Mgorny
 +
|Publication Status=Draft
 +
|Publication Date=2015/02/28
 
}}
 
}}
== Introduction ==
+
== New OpenGL management ==
 +
=== System principles ===
 +
The new OpenGL management design assumes that the reference OpenGL implementation (mesa/Xorg) is to be used to build packages. After switching to the new system, all packages will use the mesa/Xorg headers and link to the mesa/Xorg libraries. This improves portability of software built on Funtoo and solves some of the build failures when non-standard OpenGL provider was enabled.
  
Eselect (OpenGL) (also called <tt>eselect-opengl</tt>) is a module for [[Package:Eselect|Eselect]] that allows the OpenGL implementation on a Funtoo Linux or Gentoo Linux system to be switched between a variety of installed OpenGL implementations. It functions by creating an <tt>env.d</tt> file at <tt>/etc/env.d/03opengl</tt> which contains OpenGL settings, as well as managing symbolic links to OpenGL libraries and headers.
+
The third-party OpenGL libraries and modules provided by proprietary driver vendors can be enabled for run-time program use. They will not affect how the program is built. However, they will be loaded by the dynamic loader when starting executables. The Xorg server will also load the modules provided by blob driver vendor if appropriate.
 
+
=== Sample env.d File ===
+
 
+
A sample <tt>env.d</tt> file for a multilib system with xorg-x11 OpenGL implementation may look like this:
+
 
+
{{file|name=/etc/env.d/03opengl|desc=An example env.d file for eselect-opengl|body=
+
# Configuration file for eselect
+
# This file has been automatically generated.
+
LDPATH="/usr/lib32/opengl/xorg-x11/lib:/usr/lib64/opengl/xorg-x11/lib"
+
OPENGL_PROFILE="xorg-x11"
+
}}
+
 
+
== Implementation ==
+
 
+
Eselect-opengl is implemented as a single bash-based [[Package:Eselect|Eselect]] module approximately 10K in size, installed at <tt>/usr/share/eselect/modules/opengl.eselect</tt>. One interfaces with this module via the main <tt>eselect</tt> command:
+
 
+
<console>
+
# ##i##eselect opengl help
+
Manage the OpenGL implementation used by your system
+
Usage: eselect opengl <action> <options>
+
 
+
##g##Standard actions:
+
  help                      Display help text
+
  usage                    Display usage information
+
  version                  Display version information
+
 
+
##g##Extra actions:
+
  list                      List the available OpenGL implementations.
+
  set <target>              Select the OpenGL implementation.
+
    <target>                  The profile to activate
+
    --use-old                If an implementation is already set, use that one instead
+
    --prefix=<val>            Set the source prefix (default: /usr)
+
    --dst-prefix=<val>        Set the destination prefix (default: /usr)
+
    --ignore-missing          Ignore missing files when setting a new implementation
+
  show                      Print the current OpenGL implementation.
+
</console>
+
 
+
== What is Switched ==
+
 
+
Using <tt>eselect opengl set</tt> causes the following symbolic links to be updated to point to the files corresponding to the OpenGL implementation that you chose:
+
 
+
* ''Libraries'' (32-bit and 64-bit):
+
** <tt>/usr/lib(64)/libGL.so.*</tt>
+
** <tt>/usr/lib(64)/libEGL.so.*</tt>
+
** <tt>/usr/lib/(32|64|)/libGLESv1.so.*</tt>
+
** <tt>/usr/lib/(32|64|)/libGLESv2.so.*</tt>
+
* ''C Headers'':
+
** <tt>/usr/include/GL/*</tt>
+
** <tt>/usr/include/EGL/*</tt>
+
** <tt>/usr/include/KHR/*</tt>
+
* <tt>/usr/lib(64|)/xorg/modules/extensions/libglx.so</tt>
+
 
+
The symbolic links point to an installed OpenGL implementation, stored inside <tt>/usr/lib(32|64|)/opengl/(implementation-name)</tt>. These files are structured as follows:
+
 
+
* <tt>/usr/lib/opengl/(implementation-name)/lib</tt>
+
* <tt>/usr/lib/opengl/(implementation-name)/include/(GL|EGL|KHR)</tt>
+
* <tt>/usr/lib/opengl/(implementation-name)/extensions/libglx.so</tt>
+
 
+
On multilib systems, ebuilds that provide an OpenGL implementation install 32-bit libraries in <tt>/usr/lib32/opengl/(implementation name)/lib</tt> and 64-bit libraries in <tt>/usr/lib64/opengl/(implementation name)/lib</tt>.
+
 
+
== Criticisms ==
+
 
+
=== Violation of Build Consistency ===
+
 
+
As documented in {{Bug|FL-1309}}, sometimes packages fail to merge when the "wrong" eselect opengl implementation is selected. This violates Portage's ability to consistently build a package from source, assuming all its dependencies are satisfied. This could be classified as a design bug -- eselect-opengl is functioning as intended, but its underlying theory of operation is not correct.
+
 
+
== eselect-opengl-1.3* experiment ==
+
 
+
=== Introduction ===
+
 
+
As a result of {{Bug|FL-1309}}, an experimental solution was implemented in eselect-opengl-1.3*. With this version, all packages are built unconditionally against xorg-x11 OpenGL implementation and the other implementations are used only in runtime.
+
 
+
The rationale for this design change is that:
+
# There should be a consistent and repeatable build/linking process for all OpenGL applications.
+
# AMD and NVIDIA implementations of OpenGL are designed to be more of a "drop-in" runtime replacement for xorg-x11, rather than a standalone replacement for xorg-x11, and thus appear to exhibit more build-time bugs.
+
  
 
=== Implementation ===
 
=== Implementation ===
 +
The reference implementation (mesa/Xorg) packages install headers and libraries into standard system locations (/usr/include, /usr/lib*). The compiler and linker finds them using the usual rules and uses them.
  
The new version of eselect-opengl switched two files:
+
The third-party OpenGL vendors install libraries and server extension modules into vendor-named subdirectories of /usr/lib*/opengl. Those files are not used directly.
* an env.d file <tt>000opengl</tt> specifying <tt>LDPATH</tt> for the run-time implementation override,
+
* an xorg.conf.d file overriding the ModulePath for custom glx xorg modules.
+
 
+
The env.d file has the same contents as the original one, except that the name was changed to ensure that the additional linker paths are added before the system paths where xorg-x11 libraries are installed.
+
 
+
The xorg.conf.d sets ModulePaths for non-xorg module replacements (such as the nvidia glx module), if necessary.
+
 
+
=== Issues ===
+
 
+
The widespread testing of eselect-opengl-1.3* has proven some issues with the new design:
+
 
+
# <del>xorg-server is unable to handle multiple occurences of <tt>Files</tt> section gracefully. Therefore, eselect-opengl's generated xorg.conf.d file collides with many user-defined configurations.</del> (this has been patched locally and the patch is awaiting upstream review)
+
# There are rumors of arm mali's prioprietary OpenGL implementations requiring applications to be built against its own GLES headers.
+
  
{{EbuildFooter}}
+
{{Package|app-admin/eselect-opengl}} is used to select OpenGL implementation used at run-time. The choice of implementation is controlled via dynamic linker configuration (ld.so.conf) and Xorg server configuration. If the reference implementation is selected, the eselect module outputs null configuration that causes the linker and server to use the standard paths. If an another implementation is selected, the configuration prepends /usr/lib*/opengl paths to linker and server configuration, causing them to prefer the third-party libraries over reference.
 +
{{NewsFooter}}

Revision as of 18:53, February 28, 2015

New OpenGL management in Funtoo

Funtoo is switching to an improved system for managing multiple OpenGL providers (Mesa/Xorg, AMD and nVidia). The update may involve blockers and file collisions.

By Mgorny / February 28, 2015

New OpenGL management

System principles

The new OpenGL management design assumes that the reference OpenGL implementation (mesa/Xorg) is to be used to build packages. After switching to the new system, all packages will use the mesa/Xorg headers and link to the mesa/Xorg libraries. This improves portability of software built on Funtoo and solves some of the build failures when non-standard OpenGL provider was enabled.

The third-party OpenGL libraries and modules provided by proprietary driver vendors can be enabled for run-time program use. They will not affect how the program is built. However, they will be loaded by the dynamic loader when starting executables. The Xorg server will also load the modules provided by blob driver vendor if appropriate.

Implementation

The reference implementation (mesa/Xorg) packages install headers and libraries into standard system locations (/usr/include, /usr/lib*). The compiler and linker finds them using the usual rules and uses them.

The third-party OpenGL vendors install libraries and server extension modules into vendor-named subdirectories of /usr/lib*/opengl. Those files are not used directly.

Package:Eselect (OpenGL) is used to select OpenGL implementation used at run-time. The choice of implementation is controlled via dynamic linker configuration (ld.so.conf) and Xorg server configuration. If the reference implementation is selected, the eselect module outputs null configuration that causes the linker and server to use the standard paths. If an another implementation is selected, the configuration prepends /usr/lib*/opengl paths to linker and server configuration, causing them to prefer the third-party libraries over reference.

blog comments powered by Disqus