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
  30 rectangle of various sizes.
  31
  32 [All tests here are with very recent checkouts of xserver, mesa, and
  33 xf86-video-intel. Tests are run on an Intel Core 2 CPU @ 2.13GHz with
  34 an Intel 965 graphics card. Thanks, Intel for the donation of hardware
  35 for this testing!]
  36
  37 [[window-copy.png]]
  38
  39 <table border="1">
  40   <tr> <th colspan="4"> Window-to-window copy performance (Millions of pixels/sec.)
  41   <tr> <th align="right"> Rectangle size <th> 10x10 <th> 100x100 <th> 500x500
  42   <tr> <th align="right"> NoAccel <td> 14.2 <td> 26.5 <td> 23.475
  43   <tr> <th align="right"> XAA <td> 57.8 <td> 438 <td> 587.5
  44   <tr> <th align="right"> EXA <td> 77.6 <td> 464 <td> 587.5
  45 </table>
  46
  47 So here we can see that EXA is from 5 to 25 times faster for scrolling
  48 windows, depending on the size. And I can assure you that you
  49 definitely don't want windows to start scrolling 25 times slower
  50 (chug, chug, chug). Meanwhile, EXA is marginally faster than XAA on
  51 this test, but not significantly.
  52
  53 Second, let's look at another common operation, filling solid
  54 rectangles. This is an essential step in almost any rending, (for
  55 clearing to the background color), as well as for actually rendering
  56 some content.
  57
  58 [[rectangle-fill.png]]
  59
  60 <table border="1">
  61   <tr> <th colspan="5"> Solid rectangle fill rate (Millions of pixels/sec.)
  62   <tr> <th align="right"> Rectangle size <th> 1x1 <th> 10x10 <th> 100x100 <th> 500x500
  63   <tr> <th align="right"> NoAccel <td> 10.5 <td> 99.6 <td> 392 <td> 662.5
  64   <tr> <th align="right"> XAA <td> 1.5 <td> 90.9 <td> 698 <td> 842.5
  65   <tr> <th align="right"> EXA <td> 2.5 <td> 250 <td> 1150 <td> 847.5
  66 </table>
  67
  68 Again, EXA outperforms NoAccel here (from 1.3x to 2.9x faster), for
  69 all but the tiniest of rectangles. Interestingly, EXA also outperforms
  70 XAA by up to 2.7x for the 10x10 rectangle. Also, it's quite
  71 interesting to note, (and it's hard to see on the bar chart), that
  72 NoAccel outperforms EXA (4.2x) and XAA (7x) for the case of a 1x1
  73 rectangle. Presumably the overhead of setting up hardware rendering
  74 for a single-pixel object just plain isn't worth it, (which really
  75 shouldn't be that surprising).
  76
  77 So those are a couple of the operations where EXA and XAA are already
  78 performing quite well. Some of you will note that Keith Packard has
  79 often joked that an X server doesn't need more acceleration than these
  80 two operations to perform well. And if you look at the whole set of
  81 operations in the XAA interface, indeed you'll find many there that
  82 modern applications won't use at all.
  83
  84 But meanwhile, applications are now using the Render extension more
  85 and more extensively to draw things. And this is where EXA should
  86 afford some acceleration possibilities that XAA does not. And this is
  87 also where I've been identifying several problems. If "copy" and
  88 "solid fill" are the two most fundamental operations, maybe the next
  89 two are "compositing" and "compositing glyphs". I've been talking
  90 about problems in those operations for a while, and I plan to start
  91 talking about actual solutions soon.
  92
  93 Stay tuned.
  94
  95