i2p/haiku-beta6
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: Update opengl readme info

Browse Source
This commit is contained in:
Alexander von Gluck IV
2014-08-19 10:39:23 -04:00
parent 4662c8c0a9
commit ea28139d84
1 changed files with 25 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/develop/opengl/readme
+25 -79
View File
@@ -12,23 +12,14 @@ In the traditional BeOS sense, the OpenGL Add-ons are the
vendor provided OpenGL drivers. This actually doesn't vendor provided OpenGL drivers. This actually doesn't
mesh well with the current open source OpenGL stack. mesh well with the current open source OpenGL stack.
Our "OpenGL Add-ons" are really wrappers around Mesa Our "OpenGL Add-ons" are really self contained Mesa and
and Gallium code. We gain greater OS control of OpenGL Gallium renderers. On the old Mesa side of the house,
rendering with the drawback of increased work overall. swrast is a bunch of wrapper code. On the Gallium side,
The OpenGL Add-ons call private Mesa functions, thus swpipe is a Gallium target.
we get no compatibility saftey net between Mesa versions.
Our Gallium connecting Add-ons could actually fit into Mesa drivers are the classical Mesa software rasterizers,
the upstream Mesa / Gallium project, however this would Gallium drivers are the new-school software and hardware
cause complications in the build process (linking in drivers.
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.
********** **********
@@ -36,14 +27,14 @@ Mesa versions
The Haiku project uses two different versions of Mesa. The Haiku project uses two different versions of Mesa.
* Mesa 7.8.2 for gcc2 OpenGL Add-ons * Mesa 7.9.2 for gcc2 OpenGL Add-ons
* Mesa 9.0.1+ for gcc4 OpenGL Add-ons. * Mesa 10.2.0+ for gcc4 OpenGL Add-ons.
The reasoning behind this is that any version of Mesa The reasoning behind this is that any version of Mesa
above 7.8.2 will require a *massive* porting effort to above 7.9.2 will require a *massive* porting effort to
make it compile under gcc2. Given this fact, it makes make it compile under gcc2. Given this fact, it makes
sense to bump the gcc2 version of Mesa as far as it will 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 go and set it there statically. Think of Mesa 7.9.2
as the "stable" version Haiku R1 will use :) as the "stable" version Haiku R1 will use :)
Hardware 3D rendering and llvm-based software rendering Hardware 3D rendering and llvm-based software rendering
@@ -53,68 +44,23 @@ However! If you're running a gcc2 hybrid version of
Haiku, llvm or hardware based rendering should be possible Haiku, llvm or hardware based rendering should be possible
on gcc4 applications. on gcc4 applications.
It is *essential* to upgrade our build Mesa packages It's essential someone from the Haiku project keeps up
with the latest release Mesa versions. If we fall too with the upstream Mesa changes pushing build fixes to
far behind the update gets extremely tricky as functions upstream Mesa to keep Haiku relevant.
inside Mesa and Gallium change at a fast pace.
********** **********
gcc2 OpenGL kit The packages
The following process occurs in order to generate the Haiku has several packages for Mesa:
gcc2 (Mesa 7.8.2) OpenGL kit:
* Some kind soul compiles a Mesa optional package on a mesa-x.x.x-x-x86.hpkg Core Mesa package, provides libGL
gcc2 Haiku system with the bep on haikuports. This mesa_devel-x.x.x-x-x86.hpkg Provides development headers and "OpenGL kit"
gets uploaded to Haiku-files and the package name mesa_swrast-x.x.x-x-x86.hpkg Mesa "Software Rasterization" renderer
/ version gets updated as in the BuildFeatures jam mesa_swpipe-x.x.x-x-x86.hpkg Gallium "Software pipe" LLVM enhanced renderer
build script.
- The bep generally applies a few minimal patches to Future :3
Mesa 7.8.2 and compiles it. Then it rounds up all of mesa_radeonhd-x.x.x-x-x86.hpkg Gallium "Radeon HD" hardware renderer
the headers and static libraries and throws them into mesa_intel-x.x.x-x-x86.hpkg Gallium "Intel" hardware renderer
a .zip for the build mesa_nvidia-x.x.x-x-x86.hpkg Gallium "nVidia" hardware renderer (unlikely)
* 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
!!