121 lines
4.1 KiB
Plaintext
121 lines
4.1 KiB
Plaintext
|
Haiku OpenGL kit developers introduction
|
||
|
|
|
||
|
|
The Haiku OpenGL kit is made up of the folwing pieces:
|
||
|
|
|
||
|
|
* The "OpenGL Kit" aka libGL.so and supporting libraries.
|
||
|
|
This is what the user applications interact with.
|
||
|
|
|
||
|
|
* The "OpenGL Add-ons" (which do the real work)
|
||
|
|
These are chosen by the OpenGL kit and utilized
|
||
|
|
|
||
|
|
In the traditional BeOS sense, the OpenGL Add-ons are the
|
||
|
|
vendor provided OpenGL drivers. This actually doesn't
|
||
|
|
mesh well with the current open source OpenGL stack.
|
||
|
|
|
||
|
|
Our "OpenGL Add-ons" are really wrappers around Mesa
|
||
|
|
and Gallium code. We gain greater OS control of OpenGL
|
||
|
|
rendering with the drawback of increased work overall.
|
||
|
|
The OpenGL Add-ons call private Mesa functions, thus
|
||
|
|
we get no compatibility saftey net between Mesa versions.
|
||
|
|
|
||
|
|
Our Gallium connecting Add-ons could actually fit into
|
||
|
|
the upstream Mesa / Gallium project, however this would
|
||
|
|
cause complications in the build process (linking in
|
||
|
|
OpenGL and all of it's libraries into a small number of
|
||
|
|
shared libraries is not really what the Mesa project
|
||
|
|
designs it's stack for. Several symbol collisions exist
|
||
|
|
when trying to link libmesa and libgallium together for
|
||
|
|
example)
|
||
|
|
|
||
|
|
Mesa drivers are the classical Mesa software rasterizers
|
||
|
|
Gallium drivers are the new-school software drivers.
|
||
|
|
|
||
|
|
|
||
|
|
**********
|
||
|
|
Mesa versions
|
||
|
|
|
||
|
|
The Haiku project uses two different versions of Mesa.
|
||
|
|
|
||
|
|
* Mesa 7.8.2 for gcc2 OpenGL Add-ons
|
||
|
|
* Mesa 9.0.1+ for gcc4 OpenGL Add-ons.
|
||
|
|
|
||
|
|
The reasoning behind this is that any version of Mesa
|
||
|
|
above 7.8.2 will require a *massive* porting effort to
|
||
|
|
make it compile under gcc2. Given this fact, it makes
|
||
|
|
sense to bump the gcc2 version of Mesa as far as it will
|
||
|
|
go and set it there statically. Think of Mesa 7.8.2
|
||
|
|
as the "stable" version Haiku R1 will use :)
|
||
|
|
|
||
|
|
Hardware 3D rendering and llvm-based software rendering
|
||
|
|
will never work for legacy gcc2 applications. Period.
|
||
|
|
|
||
|
|
However! If you're running a gcc2 hybrid version of
|
||
|
|
Haiku, llvm or hardware based rendering should be possible
|
||
|
|
on gcc4 applications.
|
||
|
|
|
||
|
|
It is *essential* to upgrade our build Mesa packages
|
||
|
|
with the latest release Mesa versions. If we fall too
|
||
|
|
far behind the update gets extremely tricky as functions
|
||
|
|
inside Mesa and Gallium change at a fast pace.
|
||
|
|
|
||
|
|
|
||
|
|
**********
|
||
|
|
gcc2 OpenGL kit
|
||
|
|
|
||
|
|
The following process occurs in order to generate the
|
||
|
|
gcc2 (Mesa 7.8.2) OpenGL kit:
|
||
|
|
|
||
|
|
* Some kind soul compiles a Mesa optional package on a
|
||
|
|
gcc2 Haiku system with the bep on haikuports. This
|
||
|
|
gets uploaded to Haiku-files and the package name
|
||
|
|
/ version gets updated as in the BuildFeatures jam
|
||
|
|
build script.
|
||
|
|
|
||
|
|
- The bep generally applies a few minimal patches to
|
||
|
|
Mesa 7.8.2 and compiles it. Then it rounds up all of
|
||
|
|
the headers and static libraries and throws them into
|
||
|
|
a .zip for the build
|
||
|
|
|
||
|
|
* Someone starts a gcc2 Haiku build. The build process pulls
|
||
|
|
down the Mesa optional package above and links the needed
|
||
|
|
parts into libGL and the swrast_legacy OpenGL add-on
|
||
|
|
|
||
|
|
|
||
|
|
**********
|
||
|
|
gcc4 OpenGL kit
|
||
|
|
|
||
|
|
The following process occurs in order to generate the
|
||
|
|
gcc4 (Mesa 9.0.1+) OpenGL kit:
|
||
|
|
|
||
|
|
* Some kind soul compiles a Mesa optional package on a
|
||
|
|
gcc4 Haiku system with the bep on haikuports. This
|
||
|
|
gets uploaded to Haiku-files and the package name
|
||
|
|
/ version gets updated as in the BuildFeatures jam
|
||
|
|
build script.
|
||
|
|
|
||
|
|
- The kind soul also needs to install the LLVM Optional
|
||
|
|
build package on his build machine *before* compiling
|
||
|
|
the Mesa bep. (unless he or she doesn't want llvmpipe
|
||
|
|
rendering)
|
||
|
|
|
||
|
|
- The bep for Mesa 9.0.1+ doesn't apply too many patches as
|
||
|
|
Haiku build fixes are accepted upstream.
|
||
|
|
|
||
|
|
- The bep rounds up all of the headers and static
|
||
|
|
libraries and throws them into a .zip for the build
|
||
|
|
|
||
|
|
* Someone starts a gcc4 Haiku build. The build process pulls
|
||
|
|
down the Mesa optional package above and links the needed
|
||
|
|
parts into libGL and OpenGL add-ons.
|
||
|
|
|
||
|
|
- If the user didn't link in LLVM, he can disable the LLVM
|
||
|
|
dependencies in the OpenGL kit Jamfile. swpipe will
|
||
|
|
automagically fall back to softpipe rendering
|
||
|
|
|
||
|
|
- The build system will download the LLVM optional package
|
||
|
|
and link it into any OpenGL add-ons that need it.
|
||
|
|
|
||
|
|
!! The LLVM optional package needs to match the LLVM
|
||
|
|
binaries on the machine which compiled Mesa
|
||
|
|
!!
|