git.cworth.org Git - cworth.org/blob - src/exa/mozilla_i965_profiles.mdwn

   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:
   4
   5 [[mozilla_trender/i965.png]]
   6
   7 As a quick followup, here are the top functions when profiling the
   8 entire Trender suite in the NoAccel, XAA, and EXA cases.
   9
  10 [[NoAccel|noaccel.oprofile]]:
  11
  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
  27
  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.
  33
  34 [[XAA|xaa.oprofile]]:
  35
  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
  53
  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
  57 reason?
  58
  59 [[EXA|exa.oprofile]]:
  60
  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
  76
  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.
  83
  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?