[Mesa-dev] Thoughts on Haiku's OpenGL implementation (hardware rendering)

Alexander von Gluck kallisti5 at unixzen.com
Fri Jul 27 07:10:13 PDT 2012

I'm trying to get together a solid plan for Haiku's OpenGL kit.

It should be kept in mind that we indend to keep Mesa upstream code minimal
to keep from Haiku code suffering the same state as BeOS code :)

Currently we are using swrast for software rendering (which is working very
well at this point).  However the ecosystem needs expanded for proper
hardware rendering.

If you're not famular with the BeOS style GL, here is a quick primer on how
Haiku works:
* An OpenGL "kit" provides a shared library with symbols for OpenGL 
   - Mesa and gallium3d are both linked into libGL.so (which is the library 
behind the GL kit)
* The OpenGL "kit" handles the dispatch of an OpenGL renderer when 
* The dispatch code handles picking a GL renderer add-on.
Renderer add-on
While the OpenGL renderers are compiled, the Haiku build engine pulls in one 
of two
pre-compiled mesa packages which are mostly stock besides the diff's below:
- http://cgit.haiku-os.org/haiku/tree/3rdparty/mesa

Pre-compiled packages:

* Currently we have swrast (gcc4)
   A wrapper around mainline Mesa 8.1-devel swrast
* We also have swrast_legacy renderer (gcc2)
   A wrapper arround Mesa 7.8.2 (last version of mesa I could get compiled on 

I know we need a ring buffer in the driver to manage dataflow to the card, 
thoughts where the state tracker would fit in?

  -- Alexander von Gluck

More information about the mesa-dev mailing list