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

[David Reveman]

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.

> 
> 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.

-David