mesa3d-dev

[Mesa3d-dev] Adding Mesa support for 3.3.6 to XFree86

[Mike A. H. <mh...@re...>]

I'm having some trouble with Mesa that I'm not sure how to
properly handle and would like some advice.

For all of our XFree86 4.x releases, we have shipped XFree86 but
have replaced the Mesa that comes with it with the standalone
Mesa from the mesa3d project hacked to support DRI.

The reason for this is that we need software OpenGL working on
both 4.x and 3.3.6, and DRI hardware acceleration on 4.x.

This 'hack' works well, however it is somewhat of a maintenance
nightmare, because portions of the DRI code that are needed must
be extracted from our XFree86 sources first then included in the
separate Mesa packaging.  Every time XFree needs updating, the
Mesa package thus needs updating as well to keep them in sync.

There were some oddball chicken and egg dependancy problems with
this solution, and so we've decided instead of having a separate
Mesa package, to take the Mesa package and fold it into the
XFree86 src.rpm.

I've got this part working now.  Mesa builds first, and then X,
but when it comes %install time in the specfile, the two Mesa's
step on each others toes and I'm not sure how to work around it
other than intense gross hacks - that are likely to be a
maintenance nightmare in their own regards.

Currently the relevant portions of the XFree spec look like:

%install
mkdir -p $RPM_BUILD_ROOT{/usr/{include,lib},/etc/{pam.d,security/console.apps}}
make DESTDIR=$RPM_BUILD_ROOT install install.man -C xc
# FIXME: Can MESA stuff be disabled with Imake instead?
# Clean out Mesa stuff
{
   rm -f  $RPM_BUILD_ROOT/usr/include/GL
   find   $RPM_BUILD_ROOT/usr/lib -type f |grep -vi "glide"|xargs rm -f
   rm -rf $RPM_BUILD_ROOT/usr/X11R6/include/GL
   rm -f  $RPM_BUILD_ROOT/usr/X11R6/lib/lib{GL,OSM}*
}


As such, I'd like to have opinions on how to solve this dilemna
from those who actually understand how Mesa works - I am no
OpenGL guy by far.

Here is what would IMHO be the best - at least from my viewpoint
as a distributor/package maintainer:

The easiest method (for me) would be if the Mesa that comes with
XFree86 had the 3.3.6 compatibility built right into it, and was
perhaps an Imake directive to enable at X build time
(BuildMesaSupport336?).  This would make our hack unnecessary,
and would make package maintenance much simpler as well.  I'd
much rather spend my time hacking on and contributing to XFree86
itself than on packaging nightmares in unfamiliar turf...  ;o)

Alternative to that, the second method would be if in XFree86
there were Imake directives HasMesa, UseMesa like with Freetype2,
and friends, and I could stop libGL, libOSMesa, etc from being
built, and from being installed in my buildroot.  That would
remove the need for that hack we have now that deletes these
libraries during the buildroot'd install phase in the src.rpm.

Another possibility would be for us to redo the Mesa stuff and
instead of patching standalone Mesa with parts of DRI from X, if
we were to patch Mesa in X with parts of the standalone Mesa.
Not something I am comfortable with attempting myself though.

There are likely other approaches also that would work, but as
I've just started with Mesa stuff, I have no idea what is
realistic from what I've said above, and what is not.

How difficult would it be for someone familiar with the Mesa and
X code to merge the needed bits for 3.3.6 support into XFree86
sources?

Thanks in advance for any suggestions/comments/flames or help
with this matter.

TTYL


----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing

Re: [Mesa3d-dev] Adding Mesa support for 3.3.6 to XFree86

[Marcelo E. M. <mar...@bi...>]

>> "Mike A. Harris" <mh...@re...> writes:

 > For all of our XFree86 4.x releases, we have shipped XFree86 but
 > have replaced the Mesa that comes with it with the standalone
 > Mesa from the mesa3d project hacked to support DRI.
 > 
 > The reason for this is that we need software OpenGL working on
 > both 4.x and 3.3.6, and DRI hardware acceleration on 4.x.

 Hmmm... isn't this what Brian did?  Your problem is that the 3.3.6
 server doesn't have the GLX extension.  The proper hack ;-) is to teach
 the libGL in the XFree86 4 sources about fakeglx, and I'm under the
 impression Brian did this.

 > There were some oddball chicken and egg dependancy problems with
 > this solution, and so we've decided instead of having a separate
 > Mesa package, to take the Mesa package and fold it into the
 > XFree86 src.rpm.

 ugh.

 > Here is what would IMHO be the best - at least from my viewpoint
 > as a distributor/package maintainer:

 hi from one of the guys that has your job on the Debian side...

 > The easiest method (for me) would be if the Mesa that comes with
 > XFree86 had the 3.3.6 compatibility built right into it, and was
 > perhaps an Imake directive to enable at X build time
 > (BuildMesaSupport336?).  This would make our hack unnecessary,
 > and would make package maintenance much simpler as well.  I'd
 > much rather spend my time hacking on and contributing to XFree86
 > itself than on packaging nightmares in unfamiliar turf...  ;o)

 Again, your problem is that Mesa in the XFree86 4 sources doesn't work
 unless the Xserver knows about the GLX extension (IOW, you'll also have
 a problem with an XF4 server that doesn't have the GLX module
 installed).  Mesa works with 3.3.6 servers because it has a "fake" GLX
 inside it, that is, it nevers sends GLX requests to the server, but it
 handles all of that internally.

 And again, I think Brian already did the necessary work...  (I haven't
 really tested)

-- 
Marcelo

[Mesa3d-dev] Re: Adding Mesa support for 3.3.6 to XFree86

[Mike A. H. <mh...@re...>]

On Tue, 5 Jun 2001, Marcelo E. Magallon wrote:

> > For all of our XFree86 4.x releases, we have shipped XFree86 but
> > have replaced the Mesa that comes with it with the standalone
> > Mesa from the mesa3d project hacked to support DRI.
> >
> > The reason for this is that we need software OpenGL working on
> > both 4.x and 3.3.6, and DRI hardware acceleration on 4.x.
>
> Hmmm... isn't this what Brian did?  Your problem is that the 3.3.6
> server doesn't have the GLX extension.  The proper hack ;-) is to teach
> the libGL in the XFree86 4 sources about fakeglx, and I'm under the
> impression Brian did this.

Brian, can you comment on this?  If it is in fact true I'd like
to discuss it a bit deeper so that I understand what is going on
with it all.


> > There were some oddball chicken and egg dependancy problems with
> > this solution, and so we've decided instead of having a separate
> > Mesa package, to take the Mesa package and fold it into the
> > XFree86 src.rpm.
>
> ugh.

I agree.  I've successfully got it to build finally, but not
without severely evil specfile hacks.


> > Here is what would IMHO be the best - at least from my viewpoint
> > as a distributor/package maintainer:
>
> hi from one of the guys that has your job on the Debian side...

Hi.  ;o)

I don't know how Debian handles backwards compatibility with
upgrades, etc.. but that is also part of the headache for me.
Making sure nothing breaks with this.


> > The easiest method (for me) would be if the Mesa that comes with
> > XFree86 had the 3.3.6 compatibility built right into it, and was
> > perhaps an Imake directive to enable at X build time
> > (BuildMesaSupport336?).  This would make our hack unnecessary,
> > and would make package maintenance much simpler as well.  I'd
> > much rather spend my time hacking on and contributing to XFree86
> > itself than on packaging nightmares in unfamiliar turf...  ;o)
>
> Again, your problem is that Mesa in the XFree86 4 sources doesn't work
> unless the Xserver knows about the GLX extension (IOW, you'll also have

Ok.

> a problem with an XF4 server that doesn't have the GLX module
> installed).  Mesa works with 3.3.6 servers because it has a "fake" GLX
> inside it, that is, it nevers sends GLX requests to the server, but it
> handles all of that internally.

Ok, you're refering to standalone Mesa right?  Or the one
included with XFree86?  I'm assuming the former.


> And again, I think Brian already did the necessary work...  (I haven't
> really tested)

If that is true then what I am looking for above is already
implemented?  Does Mesa 3.4.2 that comes with XFree86 4.1.0
support OpenGL on 3.3.6 servers?  Brian?

If so, I can completely eliminate the separate Mesa package and
add a few more names to the people-to-buy-beer list.  ;o)



----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing

Re: [Mesa3d-dev] Re: Adding Mesa support for 3.3.6 to XFree86

[Brian P. <br...@va...>]

"Mike A. Harris" wrote:
> 
> On Tue, 5 Jun 2001, Marcelo E. Magallon wrote:
> 
> > > For all of our XFree86 4.x releases, we have shipped XFree86 but
> > > have replaced the Mesa that comes with it with the standalone
> > > Mesa from the mesa3d project hacked to support DRI.
> > >
> > > The reason for this is that we need software OpenGL working on
> > > both 4.x and 3.3.6, and DRI hardware acceleration on 4.x.
> >
> > Hmmm... isn't this what Brian did?  Your problem is that the 3.3.6
> > server doesn't have the GLX extension.  The proper hack ;-) is to teach
> > the libGL in the XFree86 4 sources about fakeglx, and I'm under the
> > impression Brian did this.
> 
> Brian, can you comment on this?  If it is in fact true I'd like
> to discuss it a bit deeper so that I understand what is going on
> with it all.

I just implemented this last week (and am still making tweaks).
Basically, I've modified the libGL that's included with XFree86
so that it can render to displays which lack the GLX extension.

First, libGL checks if the given display supports the GLX extension.
If so, we use the usual GLX code to either send GLX protocol to
the server or use the DRI to do 3D rendering.

If the display does not have the GLX extension (ala XFree86 3.3.6)
then I fallback to Xlib-based software rendering (like stand-alone
Mesa).

"fakeglx", BTW, is an emulation of the GLX programming API which
uses ordinary Xlib calls.  "xmesa" is the actual Mesa device driver
for rendering via Xlib.

Another terminology note: "GLX" refers to three things: the X
server extension, the OpenGL wire protocol, and the X/OpenGL
programming API.

I've done this work in the DRI tree on the mesa-3-5-branch branch.
Currently, the Xlib software rendering code gets built into libGL.
Alternately, we could dynamically load the rendering code as a
module, like the DRI driver.  I'm afraid that the later might be
too error prone though.

A few more comments below...



> > > There were some oddball chicken and egg dependancy problems with
> > > this solution, and so we've decided instead of having a separate
> > > Mesa package, to take the Mesa package and fold it into the
> > > XFree86 src.rpm.
> >
> > ugh.
> 
> I agree.  I've successfully got it to build finally, but not
> without severely evil specfile hacks.
> 
> > > Here is what would IMHO be the best - at least from my viewpoint
> > > as a distributor/package maintainer:
> >
> > hi from one of the guys that has your job on the Debian side...
> 
> Hi.  ;o)
> 
> I don't know how Debian handles backwards compatibility with
> upgrades, etc.. but that is also part of the headache for me.
> Making sure nothing breaks with this.
> 
> > > The easiest method (for me) would be if the Mesa that comes with
> > > XFree86 had the 3.3.6 compatibility built right into it, and was
> > > perhaps an Imake directive to enable at X build time
> > > (BuildMesaSupport336?).  This would make our hack unnecessary,
> > > and would make package maintenance much simpler as well.  I'd
> > > much rather spend my time hacking on and contributing to XFree86
> > > itself than on packaging nightmares in unfamiliar turf...  ;o)
> >
> > Again, your problem is that Mesa in the XFree86 4 sources doesn't work
> > unless the Xserver knows about the GLX extension (IOW, you'll also have
> 
> Ok.
> 
> > a problem with an XF4 server that doesn't have the GLX module
> > installed).  Mesa works with 3.3.6 servers because it has a "fake" GLX
> > inside it, that is, it nevers sends GLX requests to the server, but it
> > handles all of that internally.
> 
> Ok, you're refering to standalone Mesa right?  Or the one
> included with XFree86?  I'm assuming the former.
> 
> > And again, I think Brian already did the necessary work...  (I haven't
> > really tested)
> 
> If that is true then what I am looking for above is already
> implemented?  Does Mesa 3.4.2 that comes with XFree86 4.1.0
> support OpenGL on 3.3.6 servers?  Brian?

No.  There wasn't time to implement this and do extensive testing
in time for XFree86 4.1.0.  I don't know which XFree86 release
will get this new libGL code.


> If so, I can completely eliminate the separate Mesa package and
> add a few more names to the people-to-buy-beer list.  ;o)

Unfortunatley, I think you'll still need it for a while.

Have you looked at the BuildGLXLibrary configuration variable?
I think that might disable building XFree86's libGL entirely.

-Brian