[Mesa-dev] [PATCH] mesa/driver/haiku: Drop Mesa swrast renderer

[Alexander von Gluck IV]

On , Emil Velikov wrote:
> Hi Alexander,
> 
> On 17 May 2015 at 13:49, Alexander von Gluck IV <kallisti5 at unixzen.com> 
> wrote:
>> This just created extra upkeep and the push to move extern
>> C's into mesa code would mean a large number of extern's
>> in core Mesa driver interfaces. The Haiku Gallium renderers
>> are mostly insulated via the C-based Haiku state tracker.
>> 
>> As any future hardware support in Haiku will be gallium
>> based, lets just drop swrast.
>> 
>> Haiku has a Mesa 7.12 fork for gcc2 that uses swrast.
>> 
>> This commit fixes the last of the Haiku build issues.
> Is it worth adding mentioning in the release notes 
> (docs/relnotes/10.6.0.html) ?
> 
> Fwiw with the following hunk squashed
> Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>
> 
> --- a/src/mesa/Makefile.am
> +++ b/src/mesa/Makefile.am
> @@ -60,7 +60,6 @@ main/git_sha1.h: main/git_sha1.h.tmp
>  include Makefile.sources
> 
>  EXTRA_DIST = \
> -       drivers/haiku \
>         drivers/SConscript \
>         main/format_info.py \
>         main/format_pack.py \
> 
> On a related note - is there any reading why Haiku opted for C++
> interfaces (and no C wrappers)? Is it mostly due to some
> historical/compat reasons or more like shortage of manpower ?

Historical is some of the reason.
All of the API is C++. (as well as most of the kernel)

All of the Haiku API's (kits) are standardized and well defined.
(you should always have libGl from the "OpenGL Kit"). We have an 
Interface
kit, Open GL kit, Application kit, etc. All of our kits are internal to 
Haiku
except for Mesa as it made a lot of sense to break it out.

Here is the document on the OpenGL Kit:
https://www.haiku-os.org/legacy-docs/bebook/TheOpenGLKit_Overview.html

Here is the package recipe that generates our mesa package:
https://bitbucket.org/haikuports/haikuports/src/3ff0d11160a179c654fc7a174b977978f780ee5c/sys-libs/mesa/mesa-10.5.2.recipe?at=master

The BRenderer API is standard internally and lets us have "pluggable" 
rendering backends.
(I can take the compiled swrast renderer from Mesa 8.x and plug it into 
a machine running
Mesa 10.5 libGL without any trouble)

We were able to fit Mesa into this box by doing the following:

Haiku:

libGL.so, glapi dispatch of a BRenderer
   
(http://cgit.freedesktop.org/mesa/mesa/tree/include/HaikuGL/GLRenderer.h)

Renderers are dispatched from <prefix>/add-ons/opengl/* on a first come 
basis.
   (user over-ride prefixes, then system installed renderers. On Haiku 
all of the
    system paths are read-only)
   No renderers found results in a handy "No Renderer" on-screen error in 
GL applications.

Projects like libsdl didn't have much trouble with it:
http://hg.libsdl.org/SDL/file/7746ab058d12/src/video/haiku/SDL_bopengl.cc

So yeah, the sum of all of that is pretty much our glx is C++ :-)