Difference between pages "Usability Testing" and "News:New OpenGL management in Funtoo"

(Difference between pages)
 
(explanation of the new system)
 
Line 1: Line 1:
This page provides a place to document your install experiences, highlighting pain points so that they can be addressed in future versions of Funtoo Linux.
+
{{News
 +
|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.
 +
|News Format=Extended
 +
|News Category=Packages
 +
|Author=Mgorny
 +
|Publication Status=Draft
 +
|Publication Date=2015/02/28
 +
}}
 +
== 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.
  
== Daniel Robbins, ninja2, 12/24/2010 ==
+
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.
  
Installation of ninja2 (Dell R710) using rhel5-openvz-binaries kernel/modules/initrd .tbz2 (compiled on another machine using gcc-4.1.2) and GPT/GUID partitions. Use of binary kernel was successful although directing Portage to use the binary package was difficult - it wanted to find it inside a package repository rather than accept it directly from the command-line. Forgot to downgrade udev-160 to udev-146-r4 which resulted in a missing /etc/udev/rules.d/70-persistent-net.rules. Also didn't have brctl (bridge-utils) or ifenslave on the stage3 to allow me to set up the network correctly. Also ran into an issue with boot-update where I got the configuration wrong, because I used "kernel-[-v]" instead of "kernel[-v]". This could be a usability issue with the boot.conf syntax.
+
=== 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.
  
After getting the system booted, I ran into an issue with macaddr renaming - you can't rename a device to eth1 if eth1 already exists! So I realized the limitations of macaddr renaming using nameif (built in to the Funtoo Linux network configuration scripts.) After fixing 70-persistent-net.rules and thinking of ways we could have some kind of default assignment rather than the currently random approach, I rebooted, configured my network, firewall, OpenVZ using the masked vzctl-3.0.25-r2 -- without issue -- and had the system up and running. I found that "bc" is no longer installed by default (I thought it was) -- so I added it to the default Metro stage3. Only ~90K.
+
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.
  
Possible usability improvements:
+
{{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}}
* document use of rhel5-openvz-binaries
+
* improve Portage's ability to install binary packages by having the .tbz2 specified on the command-line
+
* improve management of udev to either force downgrade or allow multiple versions to exist on the same system (this is becoming more appealing....)
+
* add bridge-utils to default stage3 (DONE)
+
* add ifenslave to default stage3
+
* add bc to default stage3 (DONE)
+
* integrate some scheme for logically ordering ethX devices when you have many on a machine
+
* look into improving boot-update configuration syntax to avoid "-[-v]" issues that can cause thorny config problems.
+
 
+
Successes:
+
 
+
* the test of rhel5-openvz-binaries tbz2 was successful overall. It worked, and saved a ton of effort.
+
* GPT/GUID partitioning worked fine.
+
* testing of vzctl-3.0.25-r2 (currently in testing) worked perfectly.
+
* install was relatively pain-free for a pro but still needs work.
+
 
+
[[Category:QA]]
+

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.

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