Cairo with glitz backend

Chris Wilson chris at chris-wilson.co.uk
Thu Mar 5 01:42:49 PST 2009


On Thu, 2009-03-05 at 08:21 +0100, Marco wrote:
> On Wed, Mar 4, 2009 at 10:02 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 
> > So currently aside from glitz, there are experiments to show that simply
> > doing basic compositing using OpenGL can be much faster than XRender:
> > http://cgit.freedesktop.org/~anholt/cairo/log/?h=gl and
> > http://cgit.freedesktop.org/~ickle/cairo/log/?h=opengl A slightly more
> > ambitious (though it does have quite a few fundamental flaws of its own,
> > chiefly among those is that he hasn't asked anyone from the cairo
> > community to review it...)
> > http://github.com/akyrtzi/cairo-gral/tree/master And my favourite
> > (slightly biased since I'm the author ;-) is an example of what you can
> > achieve with direct rendering:
> > http://cgit.freedesktop.org/~ickle/cairo/log/?h=drm which, I claim, is
> > just about as fast as you can make cairo on an eee/i915. (I welcome any
> > patches to make it, and cairo, even faster :-)
> 
> The discussion was intriguing, so i tried your latest cairo with drm
> backend (http://cgit.freedesktop.org/~ickle/cairo/log/?h=drm) because
> I have an i915 chipset (GM45).

The gm45 is an i965 chipset, which is a different generation from i915
and although much more powerful, that same flexibility needs a different
backend. This is one of the reasons why cairo-drm is a dead-end, and
moving the EXA drivers to pixman-drm makes more sense. But writing a
specific cairo backend is much easier, and hence why I started there.

> Recompiled all the stuff with --enable-drm --enable-xlib-xrender
> --enable-dri2 --enable-gl with my brand new intel video drivers(2.6.3)
> with UXA on top of libdrm 2.4.5

I was going to add that's insufficient for drm on i915 class hardware
since tiling is fubar and you need a few extra patches to fix that up.
(Adding another user (i.e. neither X nor libGL) really helped with the
robustness of the drivers. ;-)

> I have to say that I thougth there would be a boost for all gnome
> applications, but I hardly see any difference from cairo (1.8.6)
> standard (debian packaging).
> I remember passing from standard backends to glitz showed a great
> performance boost.

The sad truth here is that cairo is not used in the most performant
manner by gnome - their usage of GdkPixbuf sucks, for example.

> How i could be sure cairo is using drm backend (apart the fact that
> libcairo is linked with libdrm)?

A cairo backend has to be explicitly created by the application, as such
apart from the dri2 test application there are no X-based cairo-drm
applications, that I know of. Instead my motivation for cairo-drm was to
accelerate cairo on wayland (which I thoroughly recommend everyone to
play with ;-)

> Are there any tests I could check to see how fast is cairo with drm backend?

The cairo performance suite in cairo/perf/ is a good starting point. It
contains mostly synthetic benchmarks, but it should provide a guide as
to how the individual operations compare. Alternatively you can record a
cairo-trace of your favourite application and replay that using any
backend and thus compare. 

If you do record an interesting trace, please submit it to the cairo
list as I'm trying to gather a set of real-world benchmarks.

> Anyway I think these new works about  cairo backends coul be very primising.

In part, I feel this a digression. The only real reason for a cairo
backend is interoperability with an acceleration architecture (xlib,
win32, quartz, [GL, DirectX]). drm/GEM is interesting as it promises to
provide a h/w accelerated image surface that should be interoperable
with both xlib and GL (and also usable in headless scenarios). However,
the real work lies in developing our existing architecture (i.e. pixman
and XRender) to benefit from recent improvements within cairo (e.g. the
shift away from tessellation to polygon rasterisation, blend modes etc)
and to complete the driver implementations to accelerate patterns.
-ickle




More information about the xorg mailing list