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
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
