[Mesa3d-dev] Building GLcore in mesa

Ian Romanick idr at us.ibm.com
Thu Mar 16 10:38:49 PST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Høgsberg wrote:

> - 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

So, there are a few files in Mesa that are shared across all loader
implementations.  I wonder if we should find a way split the generic
loader interface parts into a separate "DDK" package or something within
Mesa.  I actually have some bigger organizational changes to Mesa that
I'm going to propose at DDC, but that can wait. ;)

> - 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?

This is because with software Mesa we don't need the while remap table
mess.  That said, I'm pretty sure that we *need* that mess because of
the way the dispatch code in libglx works.  For example, if a newer
version of softgl that supports new extension functions is put on a
system with the existing libglx, it will make bad assumptions about the
dispatch offsets of those added functions.

> 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.

FOR THE LOVE OF ALL THAT IS GOOD IN THE WORLD, PLEASE YES!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEGbC4X1gOwKyEAw8RAnCVAKCbrSJj37d4yRUnLmds2nWoKY+iLQCfbS8c
N0I16CEB6XzdtMHjqX7PkWM=
=F1o2
-----END PGP SIGNATURE-----



More information about the xorg mailing list