[haiku-development] Re: OpenGL System hpkg's

  • From: Alexander von Gluck <kallisti5@xxxxxxxxxxx>
  • To: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • Date: Mon, 30 Sep 2013 16:56:55 -0500

On Mon, 2013-09-30 at 21:28 +0200, Ingo Weinhold wrote:
> On 09/30/2013 07:58 PM, Alexander von Gluck IV wrote:
> > In theory if
> > some company wanted to make their own binary OpenGL blob for us, they would
> > simply create an OpenGL add-on.  The Mesa dispatch code in our libGL.so 
> > would
> > be more than happy to dispatch non-Mesa code (there is nothing in the Mesa
> > GL dispatch code that would require it to dispatch a Mesa add-on)
> 
> I don't know about the OpenGL kit or Mesa internals. What I see, 
> however, is this: There is an external project Mesa. There is an 
> external project GLU. The Haiku build system did merges libglapi from 
> Mesa and libGLU from GLU *unchanged* into a library libGL (*). This is 
> just convoluted, particularly since GLU actually depends on libGL.

Let me cover this once more.

Our libGL.so contains:
   * Our OpenGL kit code which controls selecting the rendering add-on
     (everything in http://cgit.haiku-os.org/haiku/tree/src/kits/opengl)
   * A static dispatch library from Mesa
     (glapiLibrary) which is libglapi.a
     While this static dispatch library comes from Mesa, it is *not*
     Mesa centric.  It implements glapi which is the interface between
     opengl clients and the opengl renderer.

     The static dispatch library (from glapi) is *not* Mesa only. It can
     dispatch and launch any kind of OpenGL renderer. The calls in and
     out of glapi are standardized. This is why we have the same code in
     our OpenGL kit for GCC2 (mesa 7.8.2) and GCC4 (mesa 9.1.1).

     libGL.so *is* our OpenGL kit and doesn't contain just Mesa code.

Our OpenGL Renderers contain:
   * Our wrapper code to enable GL Rendering (extending BGLRenderer)
     http://cgit.haiku-os.org/haiku/tree/src/add-ons/opengl
   * Mesa code. What code we use in mesa differs based on what add-on
     is in use.
     - swpipe add-on includes Mesa, Gallium, llvm, and rendering code.
     - swrast add-on includes Mesa, rendering code for rasterization.


To summerize:

  libGL.so handles OpenGK clients with the BeOS OpenGL api.
  libGL.so has Mesa dispatch code in it which handles passing data
           between applications and renderers.
  OpenGL add-ons contain rendering code and generally contain most of
the relevant Mesa libraries.


From my perspective, if we decide to have kits broken into packages,
things should be designed as follows:

     Packages:
        haiku-kit-translation
            * Translation kit
        haiku-kit-translation-devel
            * Translation kit headers
        .
        .
        haiku-kit-opengl
            * OpenGL Kit
        haiku-kit-opengl-devel
            * OpenGL Kit headers
        haiku-kit-opengl-swrast
            * GCC4 software rasterization add-on (Mesa 7.8.2)
        haiku-kit-opengl-swrast-legacy
            * GCC2 software rasterization add-on (Mesa 9.1.1)
        haiku-kit-opengl-swpipe
            * GCC4 gallium software pipe renderer add-on (Mesa 9.1.1)
        haiku-kit-opengl-hwradeon
            * GCC4 gallium hardware renderer add-on (Mesa 9.1.1)
        haiku-kit-opengl-hwintel
            * GCC4 gallium hardware renderer add-on (Mesa 9.1.1)
        etc.


The base kits (haiku-kit-translation, haiku-kit-opengl) would be
requirements for Haiku.  haiku-kit-opengl-swrast or
haiku-kit-opengl-swrast_legacy would be installed by default (for now)
but removeable.

This is why I think calling our OpenGL kit "mesa" would be confusing. We
could call the add-ons mesa, however that still wouldn't be accurate as
they aren't *just* mesa code.

If applications required OpenGL, they would simply need to require
"haiku-kit-opengl".  No application should require "mesa" as we don't
have a virign "mesa" in Haiku.

 -- Alex


Other related posts: