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
!!
