System behaviour / 2d performance

cpu load / xawtv / glthreads

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.
Xmark scores

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?).
Character rendering performance
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.

previous page next page