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

   1 [[meta title="What EXA gets right already"]]
   2
   3 [[tag exa performance xorg]]
   4
   5 I've been writing various posts about [[EXA|tag/exa]] for a couple of
   6 months now. And for the most part, they've been fairly negative,
   7 (showing big slowdowns compared to running an X server without
   8 acceleration at all, for example).
   9
  10 As I've talked to people that have read the posts, it's clear that
  11 I've managed to spread some misconceptions. So let me clear things up
  12 now:
  13
  14  * Running your server with NoAccel is not a good idea
  15
  16  * EXA does accelerate a lot of things already
  17
  18  * EXA is not doomed, nor were its authors idiots to have written it
  19
  20 The reason my posts have focused on negative performance aspects is
  21 because I was looking for things that could be sped up, and as is only
  22 appropriate I looked for, found, and have been focused on the biggest
  23 performance problem with EXA I could find, (which turns out to be
  24 glyph rendering).
  25
  26 So, briefly here, I want to mention a couple of things that EXA is
  27 doing a fine job with. The first is the big reason why you don't want
  28 to run an X server with NoAccel: scrolling will hurt very badly. Take
  29 a look at these rates for a window-to-window copy of a rectangle of
  30 various sizes. These results are from "x11perf -copywinwinX" and
  31 multiplied by the number of pixels in each operation.
  32
  33 [All tests here are with very recent checkouts of xserver, mesa, and
  34 xf86-video-intel. Tests are run on an Intel Core 2 CPU @ 2.13GHz with
  35 an Intel 965 graphics card. Thanks, Intel for the donation of hardware
  36 for this testing!]
  37
  38 [[window-copy.png]]
  39
  40 <table border="1">
  41   <tr> <th colspan="4"> Window-to-window copy performance (Millions of pixels/sec.)
  42   <tr> <th align="right"> Rectangle size <th> 10x10 <th> 100x100 <th> 500x500
  43   <tr> <th align="right"> NoAccel <td> 14.2 <td> 26.5 <td> 23.475
  44   <tr> <th align="right"> XAA <td> 57.8 <td> 438 <td> 587.5
  45   <tr> <th align="right"> EXA <td> 77.6 <td> 464 <td> 587.5
  46 </table>
  47
  48 So here we can see that EXA is from 5 to 25 times faster for scrolling
  49 windows, depending on the size. And I can assure you that you
  50 definitely don't want windows to start scrolling 25 times slower
  51 (chug, chug, chug). Meanwhile, EXA is marginally faster than XAA on
  52 this test, but not significantly.
  53
  54 Second, let's look at another common operation, filling solid
  55 rectangles. This is an essential step in almost any rending, (for
  56 clearing to the background color), as well as for actually rendering
  57 some content. These results are from "x11perf -rectX", again
  58 multiplied by the number of pixels in each operation.
  59
  60 [[rectangle-fill.png]]
  61
  62 <table border="1">
  63   <tr> <th colspan="5"> Solid rectangle fill rate (Millions of pixels/sec.)
  64   <tr> <th align="right"> Rectangle size <th> 1x1 <th> 10x10 <th> 100x100 <th> 500x500
  65   <tr> <th align="right"> NoAccel <td> 10.5 <td> 99.6 <td> 392 <td> 662.5
  66   <tr> <th align="right"> XAA <td> 1.5 <td> 90.9 <td> 698 <td> 842.5
  67   <tr> <th align="right"> EXA <td> 2.5 <td> 250 <td> 1150 <td> 847.5
  68 </table>
  69
  70 Again, EXA outperforms NoAccel here (from 1.3x to 2.9x faster), for
  71 all but the tiniest of rectangles. Interestingly, EXA also outperforms
  72 XAA by up to 2.7x for the 10x10 rectangle. Also, it's quite
  73 interesting to note, (and it's hard to see on the bar chart), that
  74 NoAccel outperforms EXA (4.2x) and XAA (7x) for the case of a 1x1
  75 rectangle. Presumably the overhead of setting up hardware rendering
  76 for a single-pixel object just plain isn't worth it, (which really
  77 shouldn't be that surprising).
  78
  79 So those are a couple of the operations where EXA and XAA are already
  80 performing quite well. Some of you will note that Keith Packard has
  81 often joked that an X server doesn't need more acceleration than these
  82 two operations to perform well. And if you look at the whole set of
  83 operations in the XAA interface, indeed you'll find many there that
  84 modern applications won't use at all.
  85
  86 But meanwhile, applications are now using the Render extension more
  87 and more extensively to draw things. And this is where EXA should
  88 afford some acceleration possibilities that XAA does not. And this is
  89 also where I've been identifying several problems. If "copy" and
  90 "solid fill" are the two most fundamental operations, maybe the next
  91 two are "compositing" and "compositing glyphs". I've been talking
  92 about problems in those operations for a while, and I plan to start
  93 talking about actual solutions soon.
  94
  95 Stay tuned.
  96
  97