Re: [gentoo-dev] Modular X plans

[Ferris McCormick]

On Wed, 2005-08-10 at 17:46 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ferris McCormick wrote:
> | It always makes sense to enable glx (Mesa) whether there is DRI support
> | or not; some applications can run adequately well using the
> | Mesa-indirect approach, and some graphics cards --- e.g., Elite == afb
> | --- don't allow dri at all.  That is what (for sparc, at least) USE=glx
> | should control.
>
After a lot of experimenting, I have concluded the following:
1.  The mesa build source tree has been rearranged enough that getting
sparc assembly code to work properly is not trivial.  Instead of
building the assembly versions of the code for sparc into base libGL,
the build puts into all the dri drivers instead, thereby leaving
undefined externals if you link against libGL.  So, those flags are not
defined in the builtin mesa targets for a good reason.

2.  In case of USE=dri, for sparc right now this looks like a good set
of drivers:  DRI_DIRS = fb ffb mach64 mga radeon savage

3.  With USE=-dri, for testing purposes (and in the end, perhaps for
performance reasons as well), it seems better to change the make target
to HOSTCONF=linux-sparc, and let user's CFLAGS define the architecture.
When you do this, you get both a glx-capable libGL and a stand-alone
libGL, but no dri drivers.

4.  For now, in case USE=-dri, I am not calling fix_opengl_symlinks.
Once I have all of X11R7 into test, I'll revisit this (and the Assembly
code question) to see what gives the best performance.

These changes are not very pretty, but they have the benefit of
resulting in an ebuild for a mesa version of opengl which can actually
be tested independently from the rest of Modular X.  It is even
conceivable that other architecture/graphics-card combinations might
require something similar.

Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@g.o>
Developer, Gentoo Linux (Sparc, Devrel)