[cairo] GL backend work

Chris Wilson chris at chris-wilson.co.uk
Sat Jan 9 08:03:23 PST 2010


On Sat, 9 Jan 2010 13:40:43 +1800, Zach Laine <whatwasthataddress at gmail.com> wrote:
> On Sat, Jan 9, 2010 at 7:17 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> No problem.  I'll start this soon.  First, I want to make sure we're
> not working at cross-purposes.  What does the regression summary
> report for you from a fresh checkout of master?  Are you even working
> in master?  Your comment below about wip/compositor suggests you're
> not.

I haven't done serious work on master for months. :( My little side branch
gradually became a combination of sweeping architectural changes, new
features and bug fixes. :((

http://cgit.freedesktop.org/~ickle/cairo/log?h=wip/compositor is the
current state of broken affairs. I'm in the middle of fixing up the last
of the broken backends (which include cairo-gl at this point, the spans
interface should be 'complete' but the composite-fallbacks need work to
accommodate the lack of shaders).

> Of course.  However, since there are two backend functions paint() and
> fill(), there are two code paths.  There is no way I know of to
> enforce that fill() is implemented in terms of paint(), except by
> testing that both paths do the right thing.  This applies in lots of
> other places.

True, and I fully acknowledge that our test suite can always be improved.
However, the point I'm trying to make is that there is little difference
between paint and fill et al. Instead of shaders for the 5 high level
entry points, what I've found works well so far is to classify the
operation in terms of different fundamentals: e.g. pixel-aligned composite,
spans [non-pixel-aligned composite], and glyphs. And then use JIT shader
generation.

What I have in mind is something like:
http://cgit.freedesktop.org/~ickle/cairo/tree/src/drm/cairo-drm-i965-surface.c?h=wip/compositor#n1118

Different algorithms may require different classifications, but having
made the switch to only use the high level path interfaces, we can
decompose the task however we need to.

Hope this helps, once I've got cairo back on the road to 1.10, we should
be in a stronger position to do interesting things with cairo-gl.
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the cairo mailing list