Glucose status/instructions request, (and notes on stale branches)
airlied at gmail.com
Thu Oct 18 14:54:39 PDT 2007
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.
> > 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..
More information about the xorg