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

Alexander von Gluck IV kallisti5 at unixzen.com
Mon May 18 18:21:14 PDT 2015

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
> -       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 
kit, Open GL kit, Application kit, etc. All of our kits are internal to 
except for Mesa as it made a lot of sense to break it out.

Here is the document on the OpenGL Kit:

Here is the package recipe that generates our mesa package:

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:


libGL.so, glapi dispatch of a BRenderer

Renderers are dispatched from <prefix>/add-ons/opengl/* on a first come 
   (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:

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

More information about the mesa-dev mailing list