[cairo] Glitz surface?

[Eric Anholt]

On Mon, 2009-02-23 at 14:57 -0800, Carl Worth wrote:
> On Mon, 2009-02-23 at 20:43 +0100, Oscar Lazzarino wrote:
> > Just out of curiosity, what's the status of the "glitz" surface backend?
> 
> Experimental.
> 
> > Is it still mantained?
> 
> Not consistently. Sometimes people appear on this mailing list that
> claim to be using it actively.
> 
> > Will it ever be promoted to a non "experimental"
> > backend?
> 
> It's hard to predict the future. :-)
> 
> But the two requirements we have to mark a backend as "supported"
> instead of "experimental" are:
> 
>     1) It passes the test suite
> 
>     2) It has an obvious, active maintainer willing to keep it up
> 
> I'd soon like to be able to also add "3) It's included in our daily,
> automated testing" to that list.
> 
> > Is it worth using?
> 
> That depends a lot. As I said, some people have found it useful as is,
> (or maybe they even have patches they've been using that need to be
> landed upstream).
> 
> Other people I've talked to that are interested in doing cairo-on-opengl
> have looked at glitz and decided it's the wrong thing for several
> reasons:
> 
>     1) It targets the Render interface rather than cairo's backend
> 
>     2) It targets very old X/OpenGL infrastructure, not taking advantage
> of any recent developments, (such as actual memory management).
> 
> As an alternative, for example, Eric Anholt has recently been playing
> with a new cairo-gl backend that addresses both of these points. It's
> not yet complete in any sense, (for example, it only accelerates cairo's
> composite() interface), but he's already measured it as being 4 times
> faster than using cairo-xlib on identical hardware*.
> 
> A different approach is Chris Wilson's experimental cairo-drm backend.
> This takes advantage of code from the X server's drivers for Intel
> hardware, (rather than sitting on top of OpenGL), and presumably sees
> similar improvements.
> 
> I'll let Eric and Chris reply with pointers to their code and caveats as
> they see fit.

OK, I finally fixed the bug in Mesa that was making it hang my machine,
so I'll go ahead and show off what I've got so far.

I've got a branch in my cairo repository containing a GL backend for
cairo.  It's pretty rough -- I'm just trying to get the thing up as a
demo on my G45 system, and I think I've got it that far tonight after my
latest Mesa fixes.  It turns out that the majority of the work hasn't
been cairo, but actually just fixing the GL driver bugs.

I don't feel bad about this taking my time.  It's what I expected to
happen, and I'd rather be fixing the GL driver than fixing yet another
implementation of the 3D pipeline on my hardware.  The i915_render.c and
i965_render.c code is terrible and shouldn't be used if you can help it,
in my opinion.

Major weaknesses right now, of the top of my head:

I don't check for any extensions (haven't incorporated GLEW).  It
currently requires EXT_framebuffer_object, ARB_texture_non_power_of_two,
and ARB_texture_env_combine.  The second should be relaxed -- we can use
rectangular textures for most purposes, and this would get us i915
support.  I don't plan on ever relaxing the first -- if your GL doesn't
have EXT_fbo support, go fix your GL instead.  The third could
potentially be relaxed, but everything's got support for that extension
so it doesn't seem important to me.

Trapezoids are a killer.  50% of the CPU.  I hear the span renderer is
supposed to be Hot Stuff, and I want to take advantage of it.  However,
the interface seems to be excessive for what I want -- instead of
"please render the stroke into this 8bpp region", it relies on the
backend supporting the full interface.  This hurts bringup, and means
that code like cairo-gl and glitz doesn't take advantage of the better
rasterizer by default.  I suspect that we'll be able to rasterize the
spans and upload them as a mask about as fast as we can upload the
vertex data for the spans and render a bunch of little primitives.

Doesn't do component alpha yet.  I just haven't figured out quite how
the cairo interface works for this (the plan is to two-pass it like we
do in Render extension acceleration).

Doesn't take advantage of ARB_fbo's GL_ALPHA render target support to
cut the size of A8 surfaces used as render targets.

Doesn't take advantage of shaders at all.  This means no accelerated
gradients, and increased overhead from state manipulation.  Of course, I
haven't seen the state manipulation in the profile yet because traps are
dominating.

Doesn't expose the surfaces as either textures or FBOs for other GL
usage.  There is an obvious application of this code for integration
with clutter or other GL environments for making shinier apps.  This
should just be a matter of a couple functions and someone building an
app to show it off.

Doesn't pass the testsuite.  There are a couple of driver bugs I still
need to sort out.  There are also some subpixel offset issues that are
hurting a bunch of tests.  I'm sure it's just a bug in my code.

I also want to add EXT_texture_from_pixmap support.  Seems like this
plus xcompmgr.c plus an afternoon could get me a compositing manager
that both synced to vblank and stayed out of my way otherwise.

To get my branch and start playing with it:

git remote add anholt git://people.freedesktop.org/~anholt/cairo
git fetch anholt
git checkout -b gl anholt/gl

I'd love to see patches, though I warn in advance that I'm just doing
this in my free time and don't have too much of that to spare for
hacking on this.

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20090306/e3c338b3/attachment.pgp