1 I recently [[posted|mozilla_trender]] results showing EXA (and XAA)
2 performing quite badly on the Mozilla Trender benchmarks. As a
3 reminder, here is the chart showing the results on an i965 card:
5 [[mozilla_trender/i965.png]]
7 As a quick followup, here are the top functions when profiling the
8 entire Trender suite in the NoAccel, XAA, and EXA cases.
10 [[NoAccel|noaccel.oprofile]]:
12 CPU: Core 2, speed 2133.49 MHz (estimated)
13 Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00
14 (Unhalted core cycles) count 100000
15 samples % image name app name symbol name
16 1940211 41.7382 libxul.so libxul.so (no symbols)
17 955760 20.5605 libc-2.5.so libc-2.5.so (no symbols)
18 115195 2.4781 libfb.so libfb.so fbSolidFillmmx
19 108663 2.3376 libfb.so libfb.so fbCopyAreammx
20 78728 1.6936 libpixman.so.0.0.0 libpixman.so.0.0.0 pixman_rasterize_edges
21 76356 1.6426 libpixman.so.0.0.0 libpixman.so.0.0.0 pixmanCompositeRect
22 63186 1.3593 vmlinux vmlinux get_page_from_freelist
23 59977 1.2902 libpixman.so.0.0.0 libpixman.so.0.0.0 mmxCombineOverU
24 51859 1.1156 vmlinux vmlinux __d_lookup
25 49805 1.0714 libpixman.so.0.0.0 libpixman.so.0.0.0 pixman_image_composite
26 46590 1.0023 libpixman.so.0.0.0 libpixman.so.0.0.0 mmxCombineMaskU
28 As a baseline, this NoAccel profile looks pretty good. Mozilla itself
29 is taking up 40% of the time in its libxul code. I'm not sure if the
30 20% in libc is on behalf of mozilla or X. Meanwhile, we can see X
31 doing software rasterization and compositing with the pixman code, but
32 no single function is chewing up any large proportion of the time.
36 CPU: Core 2, speed 2133.49 MHz (estimated)
37 Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00
38 (Unhalted core cycles) count 100000
39 samples % image name app name symbol name
40 1895990 32.7139 libxul.so libxul.so (no symbols)
41 1065154 18.3785 libc-2.5.so libc-2.5.so (no symbols)
42 790802 13.6447 libpixman.so.0.0.0 libpixman.so.0.0.0 mmxCombineOverU
43 202183 3.4885 libpixman.so.0.0.0 libpixman.so.0.0.0 fbCompositeSolidMask_nx8888x8888Cmmx
44 112017 1.9328 libpixman.so.0.0.0 libpixman.so.0.0.0 fbCompositeSrc_8888x8888mmx
45 94824 1.6361 libpixman.so.0.0.0 libpixman.so.0.0.0 pixmanCompositeRect
46 84551 1.4589 libpixman.so.0.0.0 libpixman.so.0.0.0 fbCompositeSolidMask_nx8x8888mmx
47 76908 1.3270 libpixman.so.0.0.0 libpixman.so.0.0.0 pixman_rasterize_edges
48 57645 0.9946 vmlinux vmlinux system_call
49 52950 0.9136 libpixman.so.0.0.0 libpixman.so.0.0.0 mmxCombineMaskU
50 52265 0.9018 intel_drv.so intel_drv.so I830WaitLpRing
51 51640 0.8910 vmlinux vmlinux __d_lookup
52 48207 0.8318 libpixman.so.0.0.0 libpixman.so.0.0.0 pixman_image_composite_rect
54 Now, this XAA profile is certainly strange. Why has mmxCombineOverU
55 jumped up from 1% to 13%. Why should there be any more compositing
56 happening here. Is this pixel format conversion we're seeing for some
61 CPU: Core 2, speed 2133.49 MHz (estimated)
62 Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00
63 (Unhalted core cycles) count 100000
64 samples % image name app name symbol name
65 2465024 27.6332 intel_drv.so intel_drv.so i965_prepare_composite
66 1951957 21.8817 libxul.so libxul.so (no symbols)
67 1470150 16.4806 libc-2.5.so libc-2.5.so (no symbols)
68 382399 4.2867 libexa.so libexa.so ExaOffscreenMarkUsed
69 375330 4.2075 intel_drv.so intel_drv.so I830WaitLpRing
70 307074 3.4423 vmlinux vmlinux system_call
71 104493 1.1714 vmlinux vmlinux do_gettimeofday
72 97582 1.0939 intel_drv.so intel_drv.so i965_composite
73 79050 0.8862 libpixman.so.0.0.0 libpixman.so.0.0.0 pixman_rasterize_edges
74 53810 0.6032 vmlinux vmlinux __copy_to_user_ll
75 51434 0.5766 vmlinux vmlinux __d_lookup
77 And here with EXA we see some good, and some really bad. The good news
78 is that the pixman functions doing software compositing have
79 disappeared from the top of the profile, leaving only software
80 rasterization. But what's with this new i965_prepare_composite
81 function that's taking even more time than all of libxul? That seems
82 like rather excessive overhead.
84 A quick glimpse at the
85 [function](http://cgit.freedesktop.org/xorg/driver/xf86-video-intel.git/tree/src/i965_render.c),
86 (starting at line 395 or so), shows that it's just a sequence of
87 assignment statements, and then a "long sequence of commands needed to
88 set up the 3D rendering pipe". Is any of that setup redundant and
89 could it be easily eliminated?