cairo performance and poulsbo driver

[Soeren Sandmann]

Johan Bilien <jobi at via.ecp.fr> writes:

> > So I'm left wondering where the overhead of the xlib backend comes from.
> > If I run sysprof (profile attached) while running the trace (in the
> > Composite disabled case), I can see that pixman gets only 27.5% of the
> > CPU time, while 39.4% is spent "in kernel". I'm vaguely thinking that
> > these could be from moving pixmap data to and from the VRAM, but really
> > I have no idea.
> > 
> > Any idea on how to further investigate this?

The latest version of sysprof (1.1.4) can trace into the kernel as
well, but requires a 2.6.31 or later kernel though. If you don't have
that, you may want to check out

        a7a1ab3081f58557a5997a667d713186f12

from sysprof git. That is the last version that still used a
standalone module. It can also trace into the kernel.

> Profiling with oprofile shows that when running the firefox trace (xlib
> backend, Composite exa hook disabled), the CPU is idle a lot of the
> time. Maybe it's waiting for the GPU a lot?
>
> Here's the top of the profile:
> 
> 10082    33.9999  vmlinux-2.6.24-24-lpia   vmlinux-2.6.24-24-lpia
> acpi_idle_enter_bm

I don't really know what this is, but I don't think oprofile reports
CPU idle time like that. (Though I don't know oprofile very well).

> 3179     10.7207  vmlinux-2.6.24-24-lpia   vmlinux-2.6.24-24-lpia
> get_page_from_freelist

When I have seen this show up, it has been because of page faults,
often triggered from pixman_fill_sse2().

> 1662      5.6048  vmlinux-2.6.24-24-lpia   vmlinux-2.6.24-24-lpia
> acpi_idle_enter_simple
> 1317      4.4414  libpixman-1.so.0.16.2    libpixman-1.so.0.16.2
> pixman_fill_sse2
> 1080      3.6421  libpixman-1.so.0.16.2    libpixman-1.so.0.16.2
> bits_image_fetch_transformed

It doesn't show up very high, but FWIW, the pixman 0.17.2 development
snapshot has faster transformed compositing, and there will likely be
further improvements in a future 0.17.x release.


Soren