New glucose code

Alan Hourihane alanh at fairlite.demon.co.uk
Wed Mar 28 13:30:33 PDT 2007


On Wed, 2007-03-28 at 16:37 +0200, David Reveman wrote:
> On Wed, 2007-03-28 at 20:38 +0100, Alan Hourihane wrote: 
> > On Wed, 2007-03-28 at 15:29 +0200, David Reveman wrote:
> > > On Wed, 2007-03-28 at 16:07 +0100, Alan Hourihane wrote: 
> > > > Carrying on from Zack's original idea and code, I've released some new
> > > > code on the glucose-2 branch which goes all the way to allowing xorg
> > > > drivers to use the xgl acceleration paths.
> > > > 
> > > > It's a simple one line call to initialize glucose in the driver as I
> > > > mentioned in the commit message. It's...
> > > > 
> > > > glucoseScreenInit(pScreen);
> > > > 
> > > > So, initialization only need to change such as .....
> > > > 
> > > > if (!exa && !xaa)
> > > >     glucoseScreenInit(pScreen);
> > > > else if (!exa)
> > > >     driversXAAinit(...);
> > > > else
> > > >     driversEXAinit(...);
> > > > 
> > > > It also works with Mesa's software renderer too, but is obviously slow,
> > > > but useful as a testing harness.
> > > > 
> > > > There's still a few niggly issues such as server shutdown causes
> > > > failures, but I'm working on those. There are also some rendering
> > > > glitches depending on which 3D driver you use, but they could well be
> > > > problems in the respective 3D drivers. Usually good to test with Mesa by
> > > > disabling DRI to check this.
> > > > 
> > > > As I've said, all the new code is on the glucose-2 branch, but I'll be
> > > > working to stabilize it and hopefully merge to the trunk in the future.
> > > > 
> > > > If there's any comments, etc, post away, and feel free to bang on the
> > > > code.
> > > > 
> > > > Alan.
> > > 
> > > Great work Alan! This is exactly what I've been wanting to do for some
> > > time now but never got around to it.
> > > 
> > > Do you want me to move the glucose glitz backend into the glitz repo?
> > 
> > I'm not sure it makes a sense to be in glitz as it's not a client-side
> > piece of code. It's server-side only. But then there's the glitz_gl.h
> > and glitzint.h header files that I've had to replicate in the
> > server-side code. So I'm kinda torn on this. If anyone here has
> > preferences it'd be good to hear them. Otherwise I guess I'd be o.k. in
> > moving them into glitz, seeing as glucose needs glitz anyway.
> 
> I don't see any reason to why we should avoid putting the glucose
> backend where the other backends exist because it's not for client-side
> usage. I'll put it in glitz repo and add a glitz-glucose.pc file if you
> don't mind.

Sure.

 
> > > How about moving the xgl code currently in xserver/hw/xgl to xserver/xgl
> > > and avoid symlinking and building xgl sources in glucose directory?
> > 
> > I'd probably create a xserver/xgl directory and build a libxgl.a so that
> > xserver/hw/xgl can link with it and so can xserver/glucose. That should
> > avoid the symlinking as well.
> 
> That's exactly what I had in mind. Most of the xgl code really belongs
> in xserver/xgl. That includes the code in xserver/hw/xgl/glxext.

O.k. lets do that.

> > > The XF86 module part in xserver/glucose/glucose.c, if not all of
> > > glucose.c, really belongs in a xserver/hw/xfree86/glucose directory,
> > > right?
> > 
> > Not really. It's server independent. So it doesn't need to be part of
> > the xfree86 ddx. It could just as easily be used in the Darwin or
> > Windows ddx to provide acceleration on those servers.
> 
> Sure, lets move only the module part to xserver/hw/xfree86/glucose if
> using this with Darwin and/or Windows DDXs is of interest.

Already done.

Alan.




More information about the xorg mailing list