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

[Alan Hourihane]

On Wed, 2007-10-24 at 16:17 -0400, David Reveman wrote:
> On Thu, 2007-10-18 at 23:09 +0100, Alan Hourihane wrote: 
> > 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.
> 
> glitz has not seen a lot of activity lately because i'm not actively
> working on any project that require further enhancements to it. the xgl
> architecture is the big user of glitz and all known issues exposed by
> xgl through xglx has been resolved. it should be pretty solid in its
> current state, at least the window-system independent part, which is
> what you care about for glucose.

Right, which confirms what I've seen.

 
> > 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.
> 
> glitz_drawable_get_features should give you the list of GL features that
> glitz has detected and care about. GL_EXT_fbo is of course required for
> any accelerated offscreen drawing so you'll need that for any
> interesting apps to be accelerated. the xgl architecture also got some
> higher level controls for acceleration, e.g. allow acceleration if
> pixmap has been used for GLX requests, allow acceleration if pixmap has
> been used for XVideo requests, allow acceleration if pixmap dimensions
> are larger than a specified value... i'm not sure what glucose sets
> these controls to but they must also be set appropriately for any
> acceleration to take place.
> 
> it might be worth printing some of these values at startup so the user
> can tell what's accelerated and not.

Yeah, I already print out that information which should show something
like...

[XXXX] GLucose reports GLitz features as 0xXXXXXX

Alan.