Apart from testing only 3d performance, some other quick tests were
run.
xawtv was used to demonstrate overlay capabilities (for the dri and ati
driver, the XFree86 v4l module is not loaded as it misses essential
functionality).
Glthreads (from
mesa/xdemos) was used because people reported lockups with XFree86
drivers when using multiple 3d apps (especially on SMP systems) -
glthreads will create a (specified) number of threads each with its own
rendering context and own window, just displaying a rotating cube in
each window.
The "cpu load test" is done to determine if the driver behaves
reasonable, that is it shouldn't try to use all available cpu time when
it is waiting for the graphics chip and other applications are running.
To test this, glxgears or QuakeIII was run with prime95 (at the lowest
priority) running in the background, and another test consists of two
OpenGL applications running (QuakeIII + glxgears).
dri driver: xawtv worked flawlessly.
However, this driver failed the glthreads test - running only few
threads worked, however increasing the number would increase the
chances of a GPU (or X) lockup when for instance the windows were moved
around. Using more than 32 threads resulted in an immediate lockup as
soon as the 33rd context should be created.
CPU usage when running glxgears was anywhere from 3% (almost
fullscreen) to 25% (default size). CPU usage when running the quake3
timedemo in a window (size 1152x864) without other active processes
ranged from 10%-100%. Prime95 running in the
background got almost all cpu time (>95%) when a full-screen
glxgears was running. When playing QuakeIII, prime95 got about half of
all cpu time, and the QuakeIII demo four timedemo was about 15%-20%
slower compared to when nothing was run in the background. QuakeIII
remained smooth and fully playable. Running
glxgears and QuakeIII at the same time resulted in a GPU / X lockup
after a very short time (not unexpected considering the glthreads
result).
ATI driver: xawtv had some problems. Whenever starting it, the monitor
just went into sleep mode, except when it was started with -remote.
Unfortunately, the "workaround" of switching to a console and back
again to X which worked earlier didn't get the picture back, so a
reboot is required. Omitting dga support in the XF86Config file gets
rid of that (but specifiying xawtv -nodga doesn't), but of course
overlay will not work. Another workaround is using xawtv -remote, in
this case xawtv
seemed to work, but changing to fullscreen crashed it ("X Error of
failed request: BadAlloc (insufficient resources for operation),
major opcode 144 (XVideo), minor opcode 19()"), and it could no longer
be started afterwards (because the WM remembers the window
size/position so starting it again just results in the same crash at
startup). As a last desperate attempt the XFree86 v4l module was used -
xawtv then didn't crash, but there was still no TV picture, only some
static colors in the xawtv window.
Glthreads didn't run correctly - it caused a segfault after a very
short time.
CPU usage was always 100% when running a 3d application, even for the
full-screen glxgears. But don't be worried too much, the windows
drivers do this too (not tested with glxgears, but
with quake3). Prime95
got a constant 14% cpu time regardless if glxgears was run or QuakeIII
was run (both demo playback and gaming). On the upside, QuakeIII got
only less than 10% slower compared to when nothing was run in the
background. QuakeIII framerates when running glxgears simultaneously
weren't that bad, however the game was too choppy to be playable. So
this driver doesn't behave too well - the busy-waiting for the GPU
might get it some advantages when only one OpenGL application is
running, but it's not nice when multiple applications are running.
xig summit driver: xawtv didn't run too well. With the default option
(-xv) the picture looked good when it didn't exceed 512x384 (beyond
that it was mostly black and white with some strange pink and green
bars in parts of the picture), however it was impossible to change
channels. When using xawtv -noxv-video, the usage of overlay caused a
static tv picture outside xawtv's window borders in the background,
which just stayed there forever (on all virtual desktops) even when
exiting xawtv. Switching to grabdisplay worked though, interestingly
only for window sizes either not larger than 1/4 PAL (384x288) or above
PAL (768x576) between that it looked similar to what happened with the
-xv option and large sizes.
Glthreads worked flawlessly up to 64 threads, though of course the
system wasn't very responsive...
The cpu load test is interesting. If only glxgears is running without
other processes claiming cpu time, the CPU load is always 81%,
no matter how large the size of the glxgears window is. However, if
prime95 is running, glxgears doesn't get much cpu time (prime95 got
>95% cpu time). Running glxgears and QuakeIII simultaneously works
quite well, the QuakeIII framerate is noticeable slower than without
glxgears running simultaneously, but the game
remains quite smooth. Running QuakeIII simultaneously with prime95 is
also interesting, when
playing back a timedemo the playback gets quite choppy (prime95 gets
almost all and QuakeIII almost no cpu time) unless the mouse is moved
from time to time (in this case both prime95 and QuakeIII get about the
same cpu time and the timedemo score drops about 20% compared to when
nothing is run in the background). A similar pattern is shown when the
game is actually played, the framerate drops too much (and prime95 gets
a
lot of cpu time). Strangely, this doesn't happen when not only QuakeIII
and prime95, but also glxgears is running - in this case QuakeIII is
much more smooth...
Obviously, this driver tries to be
fair to other processes running and does its own scheduling, which
could give it an advantage in some cases (for example, multiple OpenGL
applications) but doesn't work too well for
the simple test case (where one OpenGL application always waits for the
GPU and a number-crunching application gets the cpu time while the
application/driver is waiting).
2d performance
2d performance was
measured with x11perf and Xmark. Xmark is just a script which weighs
the x11perf results and spits out a single score. The command used for
x11perf was
"x11perf -v1.3 -rop GXcopy GXxor -all -time 1 -repeat 3". Since Xmark
is old it doesn't test the newer functionality - especially noteworthy
is the RENDER extension which is used for rendering antialiased fonts
(it could do much more, but that's the primary usage of it for now).
I'm not too happy with using Xmark, mainly because it is 10 years old -
not only does it miss newer functionality, but the weighting of the
results might no longer be appropriate. Still, it's the standard and
nothing else is available.
The ATI driver
often locked up the X server in some of the line tests, requiring a
reboot. Thus, x11perf was run multiple times and the results combined.
The XiG Summit driver is clearly the fastest overall. The driver from
ATI not only crashed, but is just plain slow. And it's not just the
numbers which are low - in
everyday usage, it just feels sluggish.
You
can view all results (after processing
with x11perfcomp) - the first row
shows repetitions/s for the dri driver, the second row the relative performance of the ATI
driver compared to the dri driver (so a score of 3 means 3 times as
fast, 0.1 means 10 times slower), the third row shows the relative
performance of the xig summit driver compared to the dri driver. The
individual results show sometimes a lot of difference, and even the ATI
driver manages to win a couple of the 400+ subtests.
Since antialiased fonts are used quite often nowadays and Xmark doesn't
test this, this was tested additionally. For this "x11perf -aa10text"
was used (according to x11perf, this tests "Char in 80-char aa line
(Charter 10)"), in comparison to aliased fonts, "x11perf -a10text".
There are a lot of other character tests in x11perf, but unfortunately
I have no idea which ones are actually important (aa line? aa core
line?).
XiG Summit trounces the other
drivers in the antialiased character-based tests, it's about 40 times
faster. The reason for this
is likely because the RENDER extension isn't hardware accelerated
with neither ATI's nor DRI's driver
currently. Whatever the reason, this can be quite noticeable in real
world use. ATI's driver is quite slow even when using non-antialiased
fonts.
