Linux and desktop graphics

Linux and desktop graphics

Posted Sep 8, 2005 5:34 UTC (Thu) by zblaxell (subscriber, #26385)
In reply to: Linux and desktop graphics by sbergman27
Parent article: Linux and desktop graphics

"For the test, I used x11 (straight x11 rendering), xv (XVideo rendering), gl (OpenGL rendering), and gl2 (a newer, better OpenGL rendering driver)."

mplayer is not exactly a typical application--it is a video player, and video has very different system requirements than other kinds of graphics, even animated graphics. Video uses color spaces and a small set of scaling functions (which are occasionally implemented with fixed parameters to reduce software or silicon), and advanced implementations feature motion compensation functions that are utterly useless to anyone who is implementing games, CAD applications, word processors, or web browsers (or, for that matter, software video players running on very fast CPUs).

That said, I've done the test with all four of the drivers you mention. For my test I chose a 4m14s MPEG-1 352x240 file so that the decode time is not dominated by the codec. According to mplayer the video decode takes 5.7 seconds. First, let's play the file at 1:1 scaling in a window:

x11: 9.441s
xv: currently broken (see note about fragility below)
gl: 12.291s
gl2: 12.397s

OK, now instead of watching a postage stamp, let's scale those images by an integer factor of 2:

x11 + -zoom: 47.247s
xv: still broken
gl: 5.7s
gl2: 5.16s

Just to be sure I didn't screw up, I ran the benchmarks again at 1:1 resolution. 'gl' really is faster if you ask it to scale up 2:1 while it blits.

When zooming 4:1 things get slower again. At 1408x1056:

x11 + -zoom: 169.34s
gl: 23.37s
gl2: 23.72s

I generally watch most video with 'gl' at 1920x1200, which is the resolution of my laptop display, which in this case takes 59.71s, or about 23% of the time of playing the video. When 'xv' was working on this machine, it wasn't able to keep up with realtime decoding, although I can't reproduce the hard numbers now. At 1920x1200, 'x11' is just barely able to keep up with this particular video file, but at 98% CPU utilization between mplayer and the X server, 'x11' leaves less 2% of the CPU available for video decoding--even an MPEG2 file would be unplayable, and MPEG2 is pretty low-tech by modern video codec standards.

x11 is plain old X--RGBx frame buffers pushed across the video bus by the CPU. You can expect this to be the slowest or most CPU intensive of the four, unless one of the other drivers is insane (software GL is insane, or at least the Mesa libraries are completely unoptimized for simple 2D cases). Also, x11 is only fast when the ratio of video pixels to display pixels is 1:1--otherwise it gets very slow very quickly. Video tends to need weird non-integer pixel scaling to come out right on any computer display, so for real life video watching purposes x11 is useful only a last resort.

I have found 'xv' is what you want for mplayer if and only if high performance GL is unavailable. The problem with Xv is that it is incredibly fragile--it is only usable by one process at a time (including that phantom process that you just can't seem to find or kill, but which currently owns Xv so you can't run kino/xine/ogle/mplayer properly), and it tends to interact badly with text mode, virtual/physical framebuffer size mismatches, and suspend/resume cycles (software suspend2 or ACPI or APM BIOS). It took two years for the radeon driver's Xv implementation to catch up with my previous laptop's video hardware, and frankly it's still a little quirky even a year after that. Xv is also much slower than GL on my ATI Radeon 9700 AGP 8x with proprietary drivers--it just looks wrong most of the time (bad interlacing support? low frame rate? I'm not sure exactly--it was easier to switch -vo than to figure out what was wrong ;-), and needs a lot of CPU and even some framedropping to keep up with many video files. On the other hand, most of the video cards I own have sufficiently broken GL support that Xv is still quite useful.

I've never had 'gl2' work very well. It does work, but it has OSD bugs and I can't see any reason to prefer it over 'gl'. Many of the features that 'gl2' claims to have seem to also be implemented in the 'gl' driver. From what I've seen of it, 'gl2' was a newer driver at one point, and might have been better than 'gl' at the time, but eventually 'gl' got fixed more than 'gl2' did, to the point where 'gl2' is now obsolete. Maybe I don't own the one video card which is better supported by 'gl2' than 'gl' or 'xv'.

'gl' does need the CPU to do YUV->RGB colorspace conversion, but those conversions are generally cheap to do on the host CPU. I'd imagine that the GL driver is also doing DMA from the video card to move the video frames onto the display, so extra CPU on colorspace conversion is traded for less CPU on data transfer (and data transfer generally costs more).

---

(Log in to post comments)