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

[Alexander von Gluck]

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:
___
KIT
* An OpenGL "kit" provides a shared library with symbols for OpenGL 
applcations
   - 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 
requested.
   http://cgit.haiku-os.org/haiku/tree/src/kits/opengl
* The dispatch code handles picking a GL renderer add-on.
   http://cgit.haiku-os.org/haiku/tree/src/add-ons/opengl
_______________
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:
- 
http://haiku-files.org/files/optional-packages/mesa-7.8.2-x86-gcc2-2012-01-17.zip
- 
http://haiku-files.org/files/optional-packages/mesa-8.1devel-x86-gcc4-2012-06-07.zip

* 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 
gcc2)

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

  -- Alexander von Gluck