[cairo] Pixman glyph performance, and beyond!

Chris Wilson chris at chris-wilson.co.uk
Fri Oct 23 14:24:15 PDT 2009


Excerpts from Aaron Plattner's message of Fri Oct 23 21:05:07 +0100 2009:
> This is maybe only sort of related, but can we push even more of that work
> to the server?  Modern GPUs can evaluate Bezier curves very efficiently,
> and can rasterize them quickly without having to tesselate at all.  An
> approach that stores the control points in video memory and evaluates them
> using something akin to a display list call should be WAY faster than any
> amount of RLE or fancy span encoding or even sending polygons.  The server
> could always decompose it into spans if the implementation can't do the
> paths itself.

Indeed, this is the goal we are working towards. :-)

Pixman is interesting as it is both the lowest common denominator and
reference implementation, and also serves as a vital baseline against
which we can measure driver performance. If we can not render faster than
the CPU, or if we consume more power using the GPU, then our drivers suck.

At the moment, I'm looking at an incremental approach to move
tessellation to the server, and the first steps along that path would be
to use more compact mask representations and extend the current Render
protocol to match current and desired usage.

We're playing with high quality rendering of paths using the GPU via
cairo-gl. Carl has proposed to talk at LCA on this subject, so the goal
is to have something useful in place for him to demonstrate ;-). The
emphasis here, IMO, has to be to maintain cairo's high image quality -
jittered or multisampled stencil based approaches are vastly inferior
(as is the output of some other *slower* 2D libraries, I'm not bitter
;-), though there is a strong push to use those for animations where
the moving image is more forgiving to jaggies and sparkles.

My ulterior motive is then to push cairo into the X server (with cairo
talking over the wire to a cairo extension, which then uses GL or in
some of my wilder plans DRM), so that we can share the tessellation
code between client and server. Or Gallium, or other grand vision du
jour. But first, cairo-gl needs to achieve cairo-drm levels of
performance on the client (as in be faster than the CPU!), before it
becomes an intriguing prospect of pushing to the server. So in the
meantime, I'm trying to work out why the EXA/UXA drivers are so
slow, and see what we can do to improve the current architecture.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the xorg-devel mailing list