update on cairo-gl performance

[Eric Anholt-4]

Just thought I'd throw out some new numbers here in case people were
curious.  This is 2.6.32-rc4, cairo master, libdrm master, mesa master,
2d master, pixman from august 12th.  Hardware is Lenovo T61, GM965, 2G
ram, 2Ghz Core 2 Duo.

Note that this isn't apples-to-apples yet.  cairo-gl doesn't do
component alpha, so any subpixel text in these tests won't be rendered
correctly.  I'm not sure how the setup is supposed to work in a cairo
backend, so I haven't fixed it yet.  Anyone understand that?

I've done most of my profiling on firefox-talos-gfx, and through fixes
mostly in Mesa and libdrm I've got it down from upwards of 180 seconds
on this hardware to 56 seconds.  At this point, the test consumes around
90% of the CPU still, while around 10% of the time it's idle blocked on
the hardware due to the useless clears of temporary buffers.

What's coming up in cairo-gl:
      * cworth is working on GLSL.  This will reduce the CPU usage for
        state updates, and give us the framework for supporting
        gradients and possibly even better shaders for other compositing
        than we're doing today with the old nasty fixed function
        pipeline.
      * ickle is going to be avoiding the extra clears of buffers that
        are used internally in cairo.  This should be a good win for
        both xlib and gl.
      * I'm going to keep working on performance outside of cairo.  My
        next stop will be the gvim trace, I think.  Something's going
        terribly wrong with memory consumption in this one.
      * Once I've got some piglit testcases (should be soon), I'll add
        support for GL_ALPHA fbos to the intel GL drivers, which should
        cut memory bandwidth consumption for our masks.

Finally, the numbers:

[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]    image            firefox-talos-gfx   44.507   44.591   0.13%    3/3
[  0]       gl            firefox-talos-gfx   56.005   56.231   0.37%    3/3
[  0]     xlib            firefox-talos-gfx   92.570   92.631   0.15%    3/3
[  1]    image                         gvim    7.421    7.438   0.19%    3/3
[  1]       gl                         gvim   91.088   91.207   0.38%    3/3
[  1]     xlib                         gvim   49.632   49.638   0.29%    3/3
[  2]    image         firefox-planet-gnome   37.715   37.952   0.53%    3/3
[  2]       gl         firefox-planet-gnome   91.796   92.135   0.29%    3/3
[  2]     xlib         firefox-planet-gnome   48.483   48.596   0.19%    3/3
[  3]    image                    evolution    6.148    6.156   0.28%    3/3
[  3]       gl                    evolution   66.187   66.418   1.43%    3/3
[  3]     xlib                    evolution   41.207   41.226   0.98%    3/3
[  4]    image                      poppler    5.968    5.978   1.09%    3/3
[  4]       gl                      poppler   16.815   16.843   3.98%    3/3
[  4]     xlib                      poppler   35.851   35.888   0.16%    3/3
[  5]    image            firefox-talos-svg   74.505   76.889   1.48%    3/3
[  5]       gl            firefox-talos-svg  111.540  111.883   1.00%    3/3
[  5]     xlib            firefox-talos-svg   96.115   96.513   0.24%    3/3
[  6]    image         gnome-system-monitor    8.001    8.057   0.35%    3/3
[  6]       gl         gnome-system-monitor    7.865    7.891   0.55%    3/3
[  6]     xlib         gnome-system-monitor    9.322    9.547   2.79%    3/3
[  7]    image           gnome-terminal-vim    8.504    8.520   0.20%    3/3
[  7]       gl           gnome-terminal-vim   14.916   14.956   1.03%    3/3
[  7]     xlib           gnome-terminal-vim   44.785   44.864   0.95%    3/3
[  8]    image           swfdec-giant-steps    3.039    3.047   0.21%    3/3
[  8]       gl           swfdec-giant-steps   10.318   10.391   0.34%    3/3
[  8]     xlib           swfdec-giant-steps    6.883    6.929   0.57%    3/3
[  9]    image               swfdec-youtube    7.953    8.015   0.42%    3/3
[  9]       gl               swfdec-youtube    9.134    9.215   1.52%    3/3
[  9]     xlib               swfdec-youtube    5.417    5.473   0.52%    3/3


--
Eric Anholt
eric@...                         eric.anholt@...




_______________________________________________
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

[Robert O'Callahan-3]

This sounds good!

One other issue that's not being measured in your traces, which I mentioned on IRC but I should note for the record, is GTK theme drawing. The GTK theme API requires you to pass in an X drawable, so currently Gecko detects when the cairo context is a wrapper around an X drawable and the graphics state is "simple enough" (CTM is a pixel-aligned translation, operator is OVER, etc) and if so unwraps the X drawable and passes it directly to GTK.

Ideally, the GTK theme API would change so we can tell a theme to draw directly into a cairo_t (since most themes are using cairo to draw already!) Until then, though, getting theme drawing to work performantly with cairo-gl would probably require GLX_EXT_texture_from_pixmap, and of course there would still be performance impact.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

_______________________________________________
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

[Kalle Vahlman]

2009/10/21 Eric Anholt <eric@...>:
> Just thought I'd throw out some new numbers here in case people were
> curious.

Nice to see the fabeled OpenGL backend cairo finally materialize ;)

That said, I'm wondering about the requirements (or rather the target
OpenGL environment) of the backend. There is no mention of it in the
README[1] and the configure.ac check just looks for gl.pc.

I'm not too familiar with all the OpenGL flavours and drivers, but
mainly I'm wondering if

 * it's strictly directed at "desktop" OpenGL (and which version?)
 * the (to my understanding rather varying) feature/extension support
in the driver landscape is taken into account
 * and does the design allow for OpenGL ES support (though maybe that
already calls for a dedicated surface)?

Oh, and finally, if there is any demo programs using it available?
While running the test and perf suites confirm it's working at least
in some level, I'd like to see something more visual to be able to go
"look, cairo-gl!" ;)

Cheers,
  Kalle

[1] In fact,  not many of the current experimental backends are
mentioned there. Probably something that would be nice to require when
committing a new backend in the future?


--
Kalle Vahlman, zuh@...
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
See also http://syslog.movial.fi
_______________________________________________
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

[Freddie Witherden-2]

[Posting explicitly to list; Mail for some reason replies directly  
rather than to the list by default, apologies.]

On Tue, 20 Oct 2009 15:56:34 -0700, Eric Anholt <eric@...> wrote:
> I've done most of my profiling on firefox-talos-gfx, and through fixes
> mostly in Mesa and libdrm I've got it down from upwards of 180 seconds
> on this hardware to 56 seconds.  At this point, the test consumes  
> around
> 90% of the CPU still, while around 10% of the time it's idle blocked  
> on
> the hardware due to the useless clears of temporary buffers.

Have you tried the benchmark on nVidia or ATI hardware with the binary-
blob
drivers? In my experience from the Warzone 2100 project these have
significantly better support for OpenGL and should be a much more  
realistic
benchmark. (As they are much less prone to falling back to software.)

This should give a better idea of how much work is being offloaded by  
the
backend.

Regards, Freddie.

_______________________________________________
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Am 20.10.09, 15:56 -0700 schrieb Eric Anholt:
> backend, so I haven't fixed it yet.  Anyone understand that?
>
> I've done most of my profiling on firefox-talos-gfx, and through fixes
> mostly in Mesa and libdrm I've got it down from upwards of 180 seconds
> on this hardware to 56 seconds.  At this point, the test consumes around
> 90% of the CPU still, while around 10% of the time it's idle blocked on
> the hardware due to the useless clears of temporary buffers.

> Finally, the numbers:
>
> [ # ]  backend                         test   min(s) median(s) stddev. count

Does the numbers read like minutes in opposite to frames per second?

kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org

> [  0]    image            firefox-talos-gfx   44.507   44.591   0.13%    3/3
> [  0]       gl            firefox-talos-gfx   56.005   56.231   0.37%    3/3
> [  0]     xlib            firefox-talos-gfx   92.570   92.631   0.15%    3/3
> [  1]    image                         gvim    7.421    7.438   0.19%    3/3
> [  1]       gl                         gvim   91.088   91.207   0.38%    3/3
> [  1]     xlib                         gvim   49.632   49.638   0.29%    3/3
> [  2]    image         firefox-planet-gnome   37.715   37.952   0.53%    3/3
> [  2]       gl         firefox-planet-gnome   91.796   92.135   0.29%    3/3
> [  2]     xlib         firefox-planet-gnome   48.483   48.596   0.19%    3/3
> [  3]    image                    evolution    6.148    6.156   0.28%    3/3
> [  3]       gl                    evolution   66.187   66.418   1.43%    3/3
> [  3]     xlib                    evolution   41.207   41.226   0.98%    3/3
> [  4]    image                      poppler    5.968    5.978   1.09%    3/3
> [  4]       gl                      poppler   16.815   16.843   3.98%    3/3
> [  4]     xlib                      poppler   35.851   35.888   0.16%    3/3
> [  5]    image            firefox-talos-svg   74.505   76.889   1.48%    3/3
> [  5]       gl            firefox-talos-svg  111.540  111.883   1.00%    3/3
> [  5]     xlib            firefox-talos-svg   96.115   96.513   0.24%    3/3
> [  6]    image         gnome-system-monitor    8.001    8.057   0.35%    3/3
> [  6]       gl         gnome-system-monitor    7.865    7.891   0.55%    3/3
> [  6]     xlib         gnome-system-monitor    9.322    9.547   2.79%    3/3
> [  7]    image           gnome-terminal-vim    8.504    8.520   0.20%    3/3
> [  7]       gl           gnome-terminal-vim   14.916   14.956   1.03%    3/3
> [  7]     xlib           gnome-terminal-vim   44.785   44.864   0.95%    3/3
> [  8]    image           swfdec-giant-steps    3.039    3.047   0.21%    3/3
> [  8]       gl           swfdec-giant-steps   10.318   10.391   0.34%    3/3
> [  8]     xlib           swfdec-giant-steps    6.883    6.929   0.57%    3/3
> [  9]    image               swfdec-youtube    7.953    8.015   0.42%    3/3
> [  9]       gl               swfdec-youtube    9.134    9.215   1.52%    3/3
> [  9]     xlib               swfdec-youtube    5.417    5.473   0.52%    3/3
>
>
> --
> Eric Anholt
> eric@...                         eric.anholt@...
>

_______________________________________________
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

[Chris Wilson-11]

Excerpts from Kai-Uwe Behrmann's message of Thu Oct 22 06:55:59 +0100 2009:
> Am 20.10.09, 15:56 -0700 schrieb Eric Anholt:
> > Finally, the numbers:
> >
> > [ # ]  backend                         test   min(s) median(s) stddev. count
>
> Does the numbers read like minutes in opposite to frames per second?

Indeed. The measurement is the duration of the test run. Each test
represents a trace of an application doing a fixed quantity of real
work, which aims to give us a sense of overall system improvement for
each change.

As has been pointed out, they do not represent ideal cases, but
snapshots of real world usage. If an application makes a substantial
improvement to its rendering engine (like poppler has recently done), we
will drop the old trace and replace it, as we do not wish to continue
optimising for obsolete behaviour.

Similarly, it would be useful for application level benchmarks to put
the gfx system in perspective. There are few applications that are
particularly sensitive to gfx throughput (as being measured here) - but
some may be very sensitive to any latency between input and the (initial)
result being visible. And then there are applications where consistent
throughput is paramount, and even tiny stutters are highly visible - cases
where both high throughput and low, consistent, latency is required.

cairo-perf-trace has been a tremendous step forward for us to be able to
make quantifiable changes to the gfx stack. I hope that we will in the
future have similar benchmarks to drive further improvements across the
whole desktop (and shift the focus away from throughput being paramount).
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

[Eric Anholt-4]

On Thu, 2009-10-22 at 07:55 +0200, Kai-Uwe Behrmann wrote:

> Am 20.10.09, 15:56 -0700 schrieb Eric Anholt:
> > backend, so I haven't fixed it yet.  Anyone understand that?
> >
> > I've done most of my profiling on firefox-talos-gfx, and through fixes
> > mostly in Mesa and libdrm I've got it down from upwards of 180 seconds
> > on this hardware to 56 seconds.  At this point, the test consumes around
> > 90% of the CPU still, while around 10% of the time it's idle blocked on
> > the hardware due to the useless clears of temporary buffers.
>
> > Finally, the numbers:
> >
> > [ # ]  backend                         test   min(s) median(s) stddev. count
>
> Does the numbers read like minutes in opposite to frames per second?

Time in seconds.

--
Eric Anholt
eric@...                         eric.anholt@...




_______________________________________________
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo