[haiku-development] Re: OpenGL System hpkg's
- From: Alexander von Gluck IV <kallisti5@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 1 Oct 2013 10:11:26 -0500
On Tue, 01 Oct 2013 14:10:01 +0200
Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 10/01/2013 05:29 AM, Alexander von Gluck wrote:
> > On Tue, 2013-10-01 at 04:59 +0200, Ingo Weinhold wrote:
> >> I'm not so much interested in what is considered the OpenGL kit or how
> >> the libraries or the packages are called. What I am concerned with is
> >> that ATM we have three separate sets of code (Mesa, GLU, and the code in
> >> the Haiku repository) which seem to cyclically depend on each other.
> >
> > I really don't see how they are cyclical. (besides the linking libGLU
> > into libGL mess, that was Be's fault though and we can't change it
> > unless we break BeOS compat)
>
> Yes, we can change that.
>
> > libGL.so depends on Haiku API wrappers and Mesa dispatch code
>
> No. Currently libGL.so simply contains both. I don't know how the
> wrappers and the Mesa dispatch code interdepend. What I see is that the
> wrappers use internal Mesa headers. So obviously we are doing something
> that does not agree with Mesa's design.
>
> [...]
> >> So my question is: how can we reorganize things in a clean way? Note
> >> that we are not bound by how they were organized in BeOS. We can freely
> >> break up and shuffle code and libraries, as long as we keep a symlink
> >> /system/lib/libGL.so in our GCC 2 build that points to a library that --
> >> directly or indirectly -- provides all the required symbols.
> >
> > I've been moving as much code rendering code into Mesa as I can, however
> > we *have* to wrap calls at a lower level as openGL initialization isn't
> > a universal process per platform and Be's api differs from Linux,
> > Windows, and OS X (which also all differ)
>
> On Linux building Mesa results in a complete "OpenGL kit", including a
> libGL. Why is that not possible on Haiku? Why do we have to drag Mesa
> code and internal headers into Haiku's build?
>
Like I said before, Mesa 7.8.2 is the last Mesa that will compile under
gcc2. If we moved to gcc4 only, then theoretically this is possible if we
moved our OpenGL kit code into Mesa. Mesa internals change a *lot* between
versions however. Mesa 7.8.2 is much different than Mesa 9.x+
I've been able to minimize changes between versions with the current code
layout (well almost current code, I moved all of our winsys code into Mesa 9.2).
The winsys changes are in a patch, however until I can figure out how to build
Mesa 9.2, It's going to take a while to implement these changes.
On average, a Mesa update means refactoring around 4-8 lines of Mesa calls
total.
I personally don't have the free time to fork Mesa 7.8.2 and put our
OpenGL kit into it, and put our OpenGL kit into Mesa mainline. Then, work on
two differing versions of Mesa. There have been a *bunch* of reasons things
wound up like they did, 90% of them are due to anything later than Mesa 7.8.2
not building on gcc2.
Patches welcome?
-- Alex
Other related posts:
