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

(Difference between pages)
(generic_64)
 
(upgrade process & post upgrade)
 
Line 1: Line 1:
{{:Install/Header}}
+
{{News
= Funtoo Linux Sub-Architectures =
+
|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.
__NOTITLE__
+
|News Format=Extended
This page provides an overview of Funtoo Linux sub-architectures (also called ''subarches'',) designed for quick and easy reference. While this information is available in other places, such as Wikipedia, it often takes some time to study and cross-reference the various articles to get a good understanding of each type of sub-architecture, and this information generally isn't all collected neatly in one place. That is the purpose of this page. When possible, links to more detailed Wikipedia pages are provided. You are encouraged to help maintain this page as well as the Wikipedia articles referenced here.
+
|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.
  
== 64-bit Generic Processor ==
+
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.
  
=== generic_64 ===
+
=== 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 '''generic_64''' subarch is designed to support 64-bit PC-compatible CPUs, such as the [[Wikipedia:AMD_K8|AMD K8-series processors]], which were introduced in late 2003. They were notable as the first processors that supported the [[Wikipedia:X86-64|AMD64 (also called X86-64) 64-bit instruction set]] for PC-compatible systems, which was introduced as a backwards-compatible 64-bit alternative to Intel's IA-64 architecture. Intel followed suit and also began supporting this 64-bit instruction set, which they called "[[Wikipedia:X86-64#Intel_64|Intel 64]]", by releasing X86-64 64-bit compatible CPUs from mid-2004 onwards (See [[Wikipedia:X86-64#Intel_64_implementations|Intel 64 implementations.)
+
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.
  
AMD desktop 64-bit CPUs include the Athlon 64, Athlon 64 FX, Athlon 64 X2, Athlon X2, Turion 64, Turion 64 X2 and Sempron series processors. AMD server processors were released under the Opteron brand and have codenames SledgeHammer, Venus, Troy, Athens, Denmark, Italy, Egypt, Santa Ana and Santa Rosa. All Opterons released through late 2006 were based on the K8 microarchitecture with original X86-64 instructions.
+
{{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.
  
== 64-bit AMD Processors ==
+
== Upgrade information ==
 +
=== Before upgrade ===
 +
Please note that the OpenGL subsystem upgrade is a lock-step update involving file collisions and blockers. This means that a few packages need to be upgraded consecutively during a single emerge run, and during that process the OpenGL support may become temporarily broken. If the upgrade is interrupted, your system may require manual attention.
  
=== amd64-k10 ===
+
Therefore, before upgrading please make sure that you can upgrade all the following packages, if installed:
 +
* x11-base/xorg-server to 1.16.4-r1 or newer,
 +
* media-libs/mesa to 10.3.4-r1 or newer,
 +
* x11-proto/glproto to 1.4.17-r1 or newer,
 +
* x11-drivers/ati-drivers to 14.9-r2 or newer,
 +
* app-emulation/emul-linux-x86-opengl to 20140508-r1 or newer.
  
The '''amd64-k10''' subarch provides support for the [[Wikipedia:AMD10h|AMD Family 10h processors]], which were released in late 2007 as a successor to the AMD K8 series processors.
+
If you need to use an older version of one of those packages long-term, please report a bug so that we can backport the support for the new system to it.
  
Desktop amd64-k10 CPUs include [[Wikipedia:AMD Phenom|AMD Phenom]], [[Wikipedia:AMD_10h#Phenom_II_Models|AMD Phenom II]] and [[Wikipedia:AMD_10h#Athlon_II_Models|AMD Athlon II]]. Server CPUs include Opterons with codenames Budapest, Barcelona, Suzuka, Shanghai, Istanbul, Lisbon, and Magny-Cours. A full listing of amd64-k10 Opteron models [[Wikipedia:List_of_AMD_Opteron_microprocessors#K10_based_Opterons|can be found here]].
+
Additionally, please make sure to not enable FEATURES=collision-protect for the upgrade since it will involve replacing some of externally created symlinks with package files. FEATURES=protect-owned (enabled by default) is fine.
  
=== amd64-bulldozer ===
+
=== The upgrade process ===
 +
Normally, the upgrade should be performed as part of a regular @world upgrade.
  
The '''amd64-bulldozer''' subarch supports the [[Wikipedia:Bulldozer (microarchitecture)|AMD bulldozer microarchitecture]] CPUs, which were released from late 2011 through the first quarter of 2012 as a replacement for the [[Wikipedia:AMD10h|K10 microarchitecture]] CPUs.
+
However, if one desires to perform the upgrade stand-alone, he needs to pass all installed packages from the following list to emerge:
Bulldozer desktop CPUs use the [[Wikipedia:Socket_AM3+|AM3+ socket]] and server CPUs use the  [[Wikipedia:Socket_G34|G34 socket]].
+
* app-admin/eselect-opengl,
 +
* app-emulation/emul-linux-x86-opengl,
 +
* media-libs/mesa,
 +
* x11-base/xorg-server,
 +
* x11-drivers/ati-drivers,
 +
* x11-proto/glproto.
  
Desktop bulldozer CPUs include the [[Wikipedia:List_of_AMD_FX_microprocessors#.22Zambezi.22_.2832_nm_SOI.29|Zambezi FX-series CPUs]]. Server bulldozer CPUs include Opterons with codenames Zurich (Opteron 3200-series), Valencia (Opteron 4200-series) and Interlagos (Opteron 6200 series). A complete list of Opteron models [[Wikipedia:http://en.wikipedia.org/wiki/Opteron#Opteron_.2832_nm_SOI.29-_First_Generation_Bulldozer_Microarchitecture|can be found here.]].
+
=== Post upgrade ===
 +
There should be no manual steps needed after the upgrade. The currently selected OpenGL implementation will be activated automatically.
  
=== amd64-piledriver ===
+
{{NewsFooter}}
 
+
The '''amd64-piledriver''' subarch supports the [[Wikipedia:Piledriver (microarchitecture)|AMD Piledriver microarchitecture]] produced by AMD from mid-2012 through 2015, which is the successor to the [[Wikipedia:Bulldozer (microarchitecture)|AMD bulldozer microarchitecture]].
+
Piledriver CPUs and APUs are available that use the [[Wikipedia:FM2 Socket|FM2 socket]]. Desktop Piledriver CPUs use the [[Wikipedia:Socket_AM3+|AM3+ socket]]. Server Piledriver CPUs use a variety of sockets, including [[Wikipedia:Socket_AM3+|AM3+]], [[Wikipedia:Socket_C32|C32]] and [[Wikipedia:Socket_G34|G34]].
+
 
+
Desktop piledriver CPU and APUs include FX-series with codename Vishera (FX-8350, FX-8370),  [[Wikipedia:List_of_AMD_accelerated_processing_unit_microprocessors#Virgo:_.22Trinity.22_.282012.2C_32_nm.29|A-series with codename Trinity]] (A6-5400K, A10-5800K) and [[Wikipedia:http://en.wikipedia.org/wiki/List_of_AMD_accelerated_processing_unit_microprocessors#.22Richland.22_.282013.2C_32_nm.29_2|A-series with codename Richland]].
+
 
+
Server piledriver CPUs include Opterons with codenames Delhi (Opteron 3300-series, [[Wikipedia:Socket_AM3+|AM3+]]), Seoul (Opteron 4300-series, [[Wikipedia:Socket_C32|C32]])  and Abu Dhabi (Opteron 6300-series, [[Wikipedia:Socket_G34|G34]]). A full listing of Opteron models [[Wikipedia:Opteron#Opteron_.2832_nm_SOI.29_-_Piledriver_Microarchitecture|is available here]].
+
 
+
Piledriver adds several new instructions over bulldozer, so AMD bulldozer systems cannot run amd64-piledriver-optimized stages. However, this subarch is  instruction-compatible with its successor, the, so amd64-piledriver stages can run on amd64-steamroller systems, and vice versa.
+
 
+
=== amd64-steamroller ===
+
 
+
The '''amd64-steamroller''' subarch supports the  [[Wikipedia:Steamroller (microarchitecture)|AMD steamroller microarchitecture]], produced from early 2014. It is the successor to the [[Wikipedia:Piledriver (microarchitecture)|AMD Piledriver microarchitecture]].
+
Steamroller APUs are available that use the [[Wikipedia:FM2+ Socket|FM2+ socket]] and  [[Wikipedia:Socket_FP3|FP3 socket]] (mobile.)
+
 
+
Desktop steamroller APUs include the [[Wikipedia:AMD_Accelerated_Processing_Unit#Steamroller_architecture_.282014.29:_Kaveri|A-Series with codename Kaveri]], such as the quad-core AMD A10-7850K APU. Steamroller APUs are also available in mobile versions. Server steamroller APUs will include the codename Berlin APUs, which are expected to be released some time in 2015.
+
 
+
Amd64-steamroller subarches are instruction-compatible with amd64-piledriver, but add new instructions over amd64-bulldozer.
+
 
+
=== amd64-jaguar ===
+
 
+
The '''amd64-jaguar''' (also called AMD Family 16h) subarch supports the  [[Wikipedia:Jaguar (microarchitecture)|AMD jaguar microarchitecture]], which is targeted at low-power devices, including notebooks, tablets and small form-factor desktops and servers. It is perhaps most well-known for being the microarchitecture used for the [[Wikipedia:Playstation 4|Playstation 4]] and [[Wikipedia:Xbox One|Xbox One]], which each use custom 8-core Jaguar APUs.
+
Socketed Jaguar APUs use the [[Wikipedia:AM1 Socket|AM1 socket]], and  [[Wikipedia:Socket_FT3|FT3 socket]] for mobile devices. G-series [[Wikipedia:System_on_a_chip|"system on a chip" (SoC)]] APUs are available for non-socketed devices such as tablets and embedded system boards.
+
 
+
Desktop Jaguar APUs include the [[Wikipedia:List_of_AMD_accelerated_processing_unit_microprocessors#.22Kabini.22.2C_.22Temash.22_.282013.2C_28_nm.29|Kabini A-series APUs and Temash E-series APUs]], such as the Athlon 5150 and 5350 APUs, and Sempron 2650 and 3850.
+
 
+
Amd64-jaguar subarches use the MOVBE instruction which is not available on amd64-bulldozer, amd64-piledriver or amd64-steamroller. They are thus not instruction-compatible with any of these subarches.
+
{{:Install/Footer}}
+

Revision as of 19:24, 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.

Upgrade information

Before upgrade

Please note that the OpenGL subsystem upgrade is a lock-step update involving file collisions and blockers. This means that a few packages need to be upgraded consecutively during a single emerge run, and during that process the OpenGL support may become temporarily broken. If the upgrade is interrupted, your system may require manual attention.

Therefore, before upgrading please make sure that you can upgrade all the following packages, if installed:

  • x11-base/xorg-server to 1.16.4-r1 or newer,
  • media-libs/mesa to 10.3.4-r1 or newer,
  • x11-proto/glproto to 1.4.17-r1 or newer,
  • x11-drivers/ati-drivers to 14.9-r2 or newer,
  • app-emulation/emul-linux-x86-opengl to 20140508-r1 or newer.

If you need to use an older version of one of those packages long-term, please report a bug so that we can backport the support for the new system to it.

Additionally, please make sure to not enable FEATURES=collision-protect for the upgrade since it will involve replacing some of externally created symlinks with package files. FEATURES=protect-owned (enabled by default) is fine.

The upgrade process

Normally, the upgrade should be performed as part of a regular @world upgrade.

However, if one desires to perform the upgrade stand-alone, he needs to pass all installed packages from the following list to emerge:

  • app-admin/eselect-opengl,
  • app-emulation/emul-linux-x86-opengl,
  • media-libs/mesa,
  • x11-base/xorg-server,
  • x11-drivers/ati-drivers,
  • x11-proto/glproto.

Post upgrade

There should be no manual steps needed after the upgrade. The currently selected OpenGL implementation will be activated automatically.

blog comments powered by Disqus