cairo performance and poulsbo driver

[Johan Bilien]

Hi,

we are using the poulsbo driver which was written by TG for intel and is
basically a wrapper around some Xpsb binary blob.

One of our main problems nowadays is 2D performance. I have been using
the firefox-20090601 cairo trace as my benchmark, because our app is a
firefox based browser.

Running cairo master (and pixman 0.16.2), the image backend is about 3
times faster than the xlib one:

[ # ]  backend                        test  min(s) median(s) stddev.
[  0]    image            firefox-20090601  110.229  119.423  4.00% 
[  0]    xlib             firefox-20090601  297.572  298.082  0.82% 

So I thought that if I could make XRender use pixman instead of using
the driver I might be able to get closer to the image backend
performance.

I tried both disabling only the Composite hooks or all of exa's hooks,
but unfortunately I am still far from the image backend figures:

(Composite disabled)
[ # ]  backend                         test   min(s) median(s) stddev.count
[  0]     xlib             firefox-20090601  269.082  269.082   0.00% 1/1
[  0]    image             firefox-20090601  101.397  101.397   0.00% 1/1

(all EXA hooks disabled)
[ # ]  backend                         test   min(s) median(s) stddev.count
[  0]     xlib             firefox-20090601  271.958  271.958   0.00% 1/1
[  0]    image             firefox-20090601  100.829  100.829   0.00% 1/1

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?

Thanks
-- 
Johan Bilien
litl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firefox-cairo-trace-xlib-no-composite.sysprof.gz
Type: application/octet-stream
Size: 14875 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20091216/588d7348/attachment.obj>