Building GLcore in mesa

[Kristian Høgsberg]

Keith Whitwell wrote:
> It seems to me that whatever reason Xorg needs to build mesa for (I'm 
> guessing the indirect GLX software rasterizer) is a mistake.
> 
> If mesa is to be built, it should be built within the tree it is 
> developed.  That might mean that Mesa should learn how to build itself 
> in a form suitable for use as X.org's internal rasterizer, or better 
> still now that we have AIGLX approaching, that Mesa grows a DRI 
> software-only rasterizer that Xorg can use when a hardware driver for 
> AIGLX isn't available.

Funny you should mention this :)  I've been working on building the 
software rasterizer in mesa and at this point I have something that 
works, but I need to clean it up a bit, and there are a couple of issues 
that I'm not sure how to deal with.  I've renamed GLcore to softgl, 
since now it is just one implmentation of GL.  Also, this is not a 
software DRI driver, it's a implementation of the GLX provider interface 
that I added in the GLX module.  For now, I've attached a mesa patch and 
an xorg patch with my current work.  The outstanding issues in order of 
importance are:

- I use dlopen() from dix code to load softgl.so from the Xorg module
   dir.  Suggestion: We just ok dlopen() as a dix level dependency, or
   maybe do a thin wrapper as in Xgl.  All we need is load module, close
   module, lookup symbols. RTLD_LOCAL must work.  Just use flat module
   directory? Versioning?

- We still need to copy files from Mesa into the glx module.  Most of
   these are generated files:

         dispatch.h
         glapioffsets.h
         glapitable.h
         glapitemp.h
         glheader.h
         glprocs.h

   but there are a few files that I think we should just copy into xorg
   cvs:

         glapi.h
         glapi.c
         glthread.h
         glcontextmodes.c
         glcontextmodes.h


- The build order is still a bit tangled up:the xserver glx module must
   build against system installed mesa of same version as the dispatch
   files werer copied from; the glapi files end up pulling in GL/gl.h and
   GL/glx.h and they should match.  I think this is a requirement that
   could be relaxed, though, the glapi files doesn't use much from gl.h
   and glx.h.

   Conversely, softgl is an xorg module and needs xorg-sdk to be
   installed at build time, so the build order is:

         make install of mesa header files (e.g. as part of make linux-dri),
         make install of xorg-sdk (i.e. xorg server)
         make install of mesa linux-softgl target

- mesa needs to be built from scratch for this, you can't share a dri
   build tree with a softgl build tree.  Maybe this can be fixed, it's
   because of the different ways the dispatch table
   (driDispatchRemapTable) works for dri and software rendering - Ian?

- I'm adding these glx header files to the xorg sdk:

         glxserver.h
         glxscreens.h
         glxdrawable.h
         glxcontext.h
         glxext.h
         glxutil.h
         glxerror.h

   but that's temporary - I want to clean this up so I don't expose the
   glx module implementation and only install one header file, and add a
   interface versioning mechanism.

Eventually, I think we should just move xorg/GL/glx up to xorg/glx, 
since that's all it is now, but I think we should do that once we have a 
decent version control system for the server.

Oh, and is there any reason that I shouldn't just get rid of 
glx_ansic.h?  It's just gratuitously wrapping a subset of libc (deja-vu) 
for no good reason that I can see.

Kristian