[[!meta title="Correcting bugs in the rectangles test"]]

[[!tag cairo exa performance xorg]]

Owen Taylor was kind enough to take a close look at my [[!recent
post|understanding_rectangles]] comparing the performance of EXA and
NoAccel rectangle fills on an r100. He was also careful enough to
notice that the results looked really fishy.

Here are some the problems he noted from looking at the graphs:

1. The EXA line looks to have an impossibly large fill rate

2. The NoAccel line looks asymptotically linear rather than quadratic
   as expected.

3. No chart of numbers was provided to allow for any closer
   examination.

I went back to the code for my test case and did find a bug that
explains some of the problems he saw. The random positioning of
rectangles wasn't correctly accounting for their size to keep them
within the visible portion of the window. So, as the rectangle gets
larger the region that is likely to be clipped by the destination
window also gets larger. And that explains the linear rather than
quadratic growth.

So here's a corrected version of the original graphs:

[[rectangles-corrected-512.png]]

And, again, a closer look at the small rectangles:

[[rectangles-corrected-64.png]]

And, this time I'll provide a chart of numbers as well:

<table border="1" align="center">
  <tr><th colspan="3">Time to render 10000 rectangles with XRenderFillRectangles
  <tr><th>Rectangle size	<th> NoAccel (ms)	<th> EXA (ms)
  <tr><td> 1x1			<td> 1.456		<td> 2.356
  <tr><td> 2x2			<td> 1.529		<td> 2.288
  <tr><td> 4x4			<td> 1.884		<td> 2.352
  <tr><td> 8x8			<td> 3.039		<td> 2.356
  <tr><td> 16x16		<td> 3.255		<td> 2.357
  <tr><td> 32x32		<td> 7.608		<td> 2.377
  <tr><td> 64x64		<td> 26.479		<td> 2.430
  <tr><td> 128x128		<td> 101.325		<td> 5.376
  <tr><td> 256x256		<td> 1295.105		<td> 22.549
  <tr><td> 512x512		<td> 15354.022		<td> 89.744
</table>

So that addresses the second and third of Owen's issues. But what
about that fill rate? First, how can I know my card's maximum fill
rate? I'm told that the standard approach is to use `x11perf
-rect500`. Let's see what that gives for NoAccel:

	NoAccel $ x11perf -rect500
	...
	    900 reps @   6.1247 msec (   163.0/sec): 500x500 rectangle

And then for EXA:

	$ x11perf -rect500
	   3000 reps @   1.9951 msec (   501.0/sec): 500x500 rectangle

So that shows fill rates of about 41M pixels/sec for NoAccel
and about 125M pixels/sec for EXA, (`500*500*163 = 40750000`
and `500*500*501 = 125250000`).

Meanwhile, my results above for the 10000 512x512 rectangles give fill
rates of 171M pixels/sec for NoAccel and 29210M pixels/sec for EXA,
(`512*512*10000/15.354022 =~ 170733114` and `512*512*10000/.089744 =~
29210197896`).

So my test is reporting a NoAccel fill rate that is 4x faster than
what x11perf reports, and an EXA fill rate that is 233x (!) faster
than what x11perf reports. So, something is definitely still fishy
here. A fill rate of close to 30 billion pixels/sec. from an old r100
just cannot be possible, (as another datapoint, I just got a new Intel
965 and with x11perf I measure a fill rate of 843 million
pixels/sec. on it).

So what could be happening here? It could be that my cairo-perf
measurement framework is totally broken. It does at least seem to be
returning consistent numbers from one run to the next, though. And the
results do appear to have the correct trend as can be seen from these
two graphs showing the measured fill rates:

[[!img fill-rates-cairo-perf.png]]

[[!img fill-rates-x11perf.png]]

But again, notice from the Y-axis values of the cairo-perf plot that
the numbers are just plain too large to be believed.

I don't yet have a good answer for what could explain the difference
here. I did notice that exaPolyFillRect converts the list of
rectangles into a region which should prevent areas overlapped my
multiple rectangles from being filled multiple times. For x11perf
there is no overlap at 100x100 or smaller, but a lot of overlap at
500x500. Similarly, the overlap gets more probable at larger sizes
with the cairo-perf test. The existence of optimizations like that
suggest that these tests might legitimately be able to report numbers
larger than the actual fill rate of the video card.

But that code should also be common whether calling
XRenderFillRectangles like my cairo-perf test does, or XFillRectangles
like the x11perf test does. So that optimization doesn't explain what
I'm seeing here. (I also reran my cairo-perf test with
XRenderFillRectangles changed to XFillRectangles and saw no
difference.)

Anybody have any ideas what might be going on here? Email me at
<cworth@redhat.com> or the xorg list at <xorg@lists.freedesktop.org>,
([subscription required](http://lists.freedesktop.org/mailman/listinfo/xorg)
of course).