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

   1 [[!meta title="Correcting bugs in the rectangles test"]]
   2
   3 [[!tag cairo exa performance xorg]]
   4
   5 Owen Taylor was kind enough to take a close look at my [[!recent
   6 post|understanding_rectangles]] comparing the performance of EXA and
   7 NoAccel rectangle fills on an r100. He was also careful enough to
   8 notice that the results looked really fishy.
   9
  10 Here are some the problems he noted from looking at the graphs:
  11
  12 1. The EXA line looks to have an impossibly large fill rate
  13
  14 2. The NoAccel line looks asymptotically linear rather than quadratic
  15    as expected.
  16
  17 3. No chart of numbers was provided to allow for any closer
  18    examination.
  19
  20 I went back to the code for my test case and did find a bug that
  21 explains some of the problems he saw. The random positioning of
  22 rectangles wasn't correctly accounting for their size to keep them
  23 within the visible portion of the window. So, as the rectangle gets
  24 larger the region that is likely to be clipped by the destination
  25 window also gets larger. And that explains the linear rather than
  26 quadratic growth.
  27
  28 So here's a corrected version of the original graphs:
  29
  30 [[rectangles-corrected-512.png]]
  31
  32 And, again, a closer look at the small rectangles:
  33
  34 [[rectangles-corrected-64.png]]
  35
  36 And, this time I'll provide a chart of numbers as well:
  37
  38 <table border="1" align="center">
  39   <tr><th colspan="3">Time to render 10000 rectangles with XRenderFillRectangles
  40   <tr><th>Rectangle size        <th> NoAccel (ms)       <th> EXA (ms)
  41   <tr><td> 1x1                  <td> 1.456              <td> 2.356
  42   <tr><td> 2x2                  <td> 1.529              <td> 2.288
  43   <tr><td> 4x4                  <td> 1.884              <td> 2.352
  44   <tr><td> 8x8                  <td> 3.039              <td> 2.356
  45   <tr><td> 16x16                <td> 3.255              <td> 2.357
  46   <tr><td> 32x32                <td> 7.608              <td> 2.377
  47   <tr><td> 64x64                <td> 26.479             <td> 2.430
  48   <tr><td> 128x128              <td> 101.325            <td> 5.376
  49   <tr><td> 256x256              <td> 1295.105           <td> 22.549
  50   <tr><td> 512x512              <td> 15354.022          <td> 89.744
  51 </table>
  52
  53 So that addresses the second and third of Owen's issues. But what
  54 about that fill rate? First, how can I know my card's maximum fill
  55 rate? I'm told that the standard approach is to use `x11perf
  56 -rect500`. Let's see what that gives for NoAccel:
  57
  58         NoAccel $ x11perf -rect500
  59         ...
  60             900 reps @   6.1247 msec (   163.0/sec): 500x500 rectangle
  61
  62 And then for EXA:
  63
  64         $ x11perf -rect500
  65            3000 reps @   1.9951 msec (   501.0/sec): 500x500 rectangle
  66
  67 So that shows fill rates of about 41M pixels/sec for NoAccel
  68 and about 125M pixels/sec for EXA, (`500*500*163 = 40750000`
  69 and `500*500*501 = 125250000`).
  70
  71 Meanwhile, my results above for the 10000 512x512 rectangles give fill
  72 rates of 171M pixels/sec for NoAccel and 29210M pixels/sec for EXA,
  73 (`512*512*10000/15.354022 =~ 170733114` and `512*512*10000/.089744 =~
  74 29210197896`).
  75
  76 So my test is reporting a NoAccel fill rate that is 4x faster than
  77 what x11perf reports, and an EXA fill rate that is 233x (!) faster
  78 than what x11perf reports. So, something is definitely still fishy
  79 here. A fill rate of close to 30 billion pixels/sec. from an old r100
  80 just cannot be possible, (as another datapoint, I just got a new Intel
  81 965 and with x11perf I measure a fill rate of 843 million
  82 pixels/sec. on it).
  83
  84 So what could be happening here? It could be that my cairo-perf
  85 measurement framework is totally broken. It does at least seem to be
  86 returning consistent numbers from one run to the next, though. And the
  87 results do appear to have the correct trend as can be seen from these
  88 two graphs showing the measured fill rates:
  89
  90 [[!img fill-rates-cairo-perf.png]]
  91
  92 [[!img fill-rates-x11perf.png]]
  93
  94 But again, notice from the Y-axis values of the cairo-perf plot that
  95 the numbers are just plain too large to be believed.
  96
  97 I don't yet have a good answer for what could explain the difference
  98 here. I did notice that exaPolyFillRect converts the list of
  99 rectangles into a region which should prevent areas overlapped my
 100 multiple rectangles from being filled multiple times. For x11perf
 101 there is no overlap at 100x100 or smaller, but a lot of overlap at
 102 500x500. Similarly, the overlap gets more probable at larger sizes
 103 with the cairo-perf test. The existence of optimizations like that
 104 suggest that these tests might legitimately be able to report numbers
 105 larger than the actual fill rate of the video card.
 106
 107 But that code should also be common whether calling
 108 XRenderFillRectangles like my cairo-perf test does, or XFillRectangles
 109 like the x11perf test does. So that optimization doesn't explain what
 110 I'm seeing here. (I also reran my cairo-perf test with
 111 XRenderFillRectangles changed to XFillRectangles and saw no
 112 difference.)
 113
 114 Anybody have any ideas what might be going on here? Email me at
 115 <cworth@redhat.com> or the xorg list at <xorg@lists.freedesktop.org>,
 116 ([subscription required](http://lists.freedesktop.org/mailman/listinfo/xorg)
 117 of course).