cairo performance and poulsbo driver
sandmann at daimi.au.dk
Fri Dec 18 21:11:00 PST 2009
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
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
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
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
> 1317 4.4414 libpixman-1.so.0.16.2 libpixman-1.so.0.16.2
> 1080 3.6421 libpixman-1.so.0.16.2 libpixman-1.so.0.16.2
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.
More information about the xorg