Glucose status/instructions request, (and notes on stale branches)

[Alan Hourihane]

On Fri, 2007-10-19 at 07:54 +1000, Dave Airlie wrote:
> On 10/19/07, Alan Hourihane <alanh at fairlite.demon.co.uk> wrote:
> > On Fri, 2007-10-19 at 07:26 +1000, Dave Airlie wrote:
> > > On 10/19/07, Alan Hourihane <alanh at fairlite.demon.co.uk> wrote:
> > > > On Wed, 2007-10-17 at 22:08 -0700, Keith Packard wrote:
> > > > > On Wed, 2007-10-17 at 19:33 +0100, Alan Hourihane wrote:
> > > > >
> > > > > > I'm hoping to merge this to trunk pretty soon for both xserver and intel
> > > > > > code once the final couple of niggles are sorted out.
> > > > >
> > > > > I do not want this merged to trunk for xserver or the intel driver at
> > > > > this point. I consider it an important research project but not
> > > > > something I want to encourage distributions and other X.org consumers to
> > > > > use in the near term.
> > > >
> > > > Why Keith ? Any technical reason ?
> > > >
> > > > It's an optional component, no one is forced to use it.
> > >
> > > While I don't agree with Keith's stance I really would like to see
> > > glucose useable before hitting master, granted I think most of the
> > > improvements required are in the 3D drivers not in the render->GL
> > > conversion..
> > >
> > > 1. does it still rely on glitz? why? if so can we remove that?
> >
> > It does as it's based on the same acceleration paths from Xgl so it's
> > reduced the effort to get a GL acceleration path up and running.
> >
> > Optimisation is always the fun stuff in GL, so we could remove or
> > optimise glitz, but the code works as it stands and optimisation is
> > always a never-ending game.
> 
> I'm asking more about have an external library dependency with an
> unknown API status? is the glitz api stable etc... if distros have to
> ship it it would be nice to know how supported the external libs and
> the code are going forward or if we need to hold off until the APIs
> have been solidified.

We're going to need an some form of API for glucose to sit on. GL
drivers can export differing levels of functionality so we'll really
want to query the drivers capabilities and choose the best GL paths.
Glitz already does this and chooses those paths. 

Granted glitz has not seen a lot of activity lately, and maybe why it
hasn't is because it seems pretty solid. It'd be useful for Dave Reveman
to comment further on glitz.

One of the items I need to do is run glitz through xtest to at least
ensure X rendering is done correctly.

> > > 2. does it go fast yet on any 3D driver? can we get example codepaths
> > > into one 3D driver so we can copy it?
> >
> > Both myself and Jose have tested successfully on 945G hardware, and it
> > works really well with current Mesa/DRM head & xserver glucose-2 code.
> >
> > The wiki page shows it's current status and there's a couple of issues
> > to get resolved, before I want to bring to master.
> 
> I've tested it on my 915 and I noticed it hitting a lot of sw paths
> for doing a lot of stuff, hence why I asked for perhaps a list of
> proposed 3D driver changes or ideas for other 3D driver writers how to
> optimise for the glucose so it at least uses hw in most cases..

As above, glitz is responsible for querying the GL and setting up it's
own acceleration paths. Maybe the i915 3D driver you are using has a bug
someplace. So was hitting a slower path. But I can certainly pull those
query paths from glitz and update the wiki page with that current
information.

Alan.