--- /dev/null
+[[meta title="A first look at Glucose on the i965"]]
+
+[[tag xorg exa performance i965]]
+
+As readers of my blog know, I've been working on improving the Intel
+965 driver within the [EXA](http://cworth.org/tag/exa/) acceleration
+architecture of the X server. Meanwhile, there's an alternate
+acceleration architecture originally
+[announced](http://lists.freedesktop.org/archives/xorg/2006-August/017527.html)
+by Zack Rusin in August 2006 called Glucose. The idea with Glucose is
+to accelerate X rendering operations by using OpenGL.
+
+Recently there's been a fair amount of activity in the various Glucose
+branches, so I thought I'd take a look to see how well it's
+working. This was quite convenient for me as the current Glucose work
+is focused only on Intel cards. Since Glucose isn't quite ready for
+prime-time yet, it does require fetching various non-master branches
+of several git repositories. It's not always obvious which branches to
+take, so José Fonseca was kind enough to writeup some [Glucose build
+instructions](http://www.freedesktop.org/wiki/Software/Glucose).
+
+I've followed those instructions and run a benchmark comparing Glucose
+and EXA. The benchmark I chose is the expedite application that comes
+with evas, (thanks to the people that kindly pointed out this newer
+benchmark to me after m recent
+[explorations](http://cworth.org/exa/i965/render_bench/) with the
+older render_bench). To get expedite you'll need the e17/libs/evas and
+e17/apps/expedite modules from [enlightenment
+CVS](http://enlightenment.org/p.php?p=download/cvs&l=en).
+
+Expedite is a nice benchmark in that it separates things like image
+blending and text rendering into separate tests, (unlike
+render_bench). It's also nice that evas includes many backends which
+can be interesting for comparison, (though I won't be looking at
+anything but its XRender-based backends here---and it looks like evas'
+cairo and OpenGL backends are not currently functional).
+
+So here are the results I got for three acceleration architectures:
+
+ 1. XAA with the XAANoOffscreenPixmaps option, (this is an
+ all-software implementation for reference).
+
+ 2. Glucose---the new thing we're looking at here.
+
+ 3. EXA, (as available in the various glucose branches---so without
+ things like my recent glyph-pixmaps work).
+
+The results are all normalized to the performance of our baseline,
+XAA. And larger numbers are better.
+
+[[img expedite.png]]
+
+The [raw
+data](http://cworth.org/glucose/i965/first_look/expedite.data) is also
+available for anyone with particular interest, (it has non-normalized
+values as well as results from evas' software backends using both SDL
+and X11 for image transport).
+
+The quick conclusion is that, so far, I'm not getting any benefit from
+running Glucose as compared to just running an all-software
+implementation, (see how all Glucose and XAA bars are basically
+identical). I might still not have everything compiled or running
+correctly yet, but I'm quite sure that at least _some_ Glucose code
+was active during my Glucose run. That's because a glucose module
+failed to find a required symbol and crashed during the "Polygon
+Blend" test, (which is why it doesn't have a bar in the chart, nor is
+there a number for the overall "EVAS SPEED" result for Glucose).
+
+Meanwhile, it's also clear that EXA is going far too slow for text
+operations. This isn't any surprise since I've documented problems
+with slow text rendering on the i965 several times before. However,
+I've never before measured text rendering that's _quite_ this
+slow. I'm seeing speeds of only about 30k glyphs/sec. with EXA on
+these branches, while my previous testing always showed about 100k
+glyphs/sec. I suspect that there's been some regression somewhere in
+the X server or the Intel driver, (and likely unrelated to anything
+about Glucose---Keith has reported similar slowness with builds from
+the master branches).
+
+Another interesting thing to look at is the difference caused by the
+"few" variants of the "Rect Blend" and "Rect Solid" tests. When going
+from the non-few to the "few" variants, both Glucose and EXA slow down
+significantly. I'm quite happy to see these tests in this benchmark
+since it is often the setup overhead that kills you when trying to
+accelerate a small number of operations, (and applications have a
+tendency to want to do that very often). Many synthetic benchmarks are
+extremely non-useful in hiding this overhead by doing huge batches of
+operations.
+
+Meanwhile, I'm still working on fixing the horribly slow compositing
+problems in the i965 driver that are keeping text so slow. Keith
+Packard and Eric Anholt are helping me debug my code, and hopefully
+we'll soon have something to show which runs at a reasonable speed.
+
projects / cworth.org / blobdiff