1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

2008 Linux Graphics Survey Results

Michael Larabel

Published on 22 December 2008
Written by Michael Larabel
Page 1 of 6 - 33 Comments

Last week our annual Linux Graphics Survey ended. There were over 14,000 submissions this year to the eleven questions we asked pertaining to X.Org, Linux desktop usage, and graphics hardware. In this article are all of the results from this year's survey.

The first question we had asked were which of the listed X.Org areas are you most interested in as an end-user.

By far the area that most users are interested in is kernel mode-setting. For those who have yet to familiarize themselves with kernel mode-setting, it involves moving all of the mode-setting handling from the X.Org DDX driver and into the Linux kernel. The benefits of this include a flicker-free boot process since the GPU only needs to set its mode once, fast VT switching, the possibility of having graphical failure messages (think the Windows Blue Screen of Death on Windows), and ultimately should lead to a more robust environment.

Kernel-based mode-setting isn't even entering the mainline kernel until Linux 2.6.29 but it has been shipping as a preview feature in Fedora for a while (A Preview of KMS). Red Hat has already developed Plymouth, which is a replacement for the Red Hat Graphical Boot (RHGB) program that relies upon kernel mode-setting for providing a pleasant boot experience with a number of other advantages too. Another project coming about is Wayland, which also leverages kernel mode-setting to provide a mini display server with an integrated compositing manager.

Kernel mode-setting should really start to come into play next year when it enters the mainline Linux kernel and begins appearing in other distributions as a stable feature. There are already plans for Ubuntu 9.10 to adopt Plymouth. In the Linux 2.6.29 kernel there will be KMS support for Intel graphics while the ATI KMS support will go mainline later on. The Nouveau KMS support is still in development and the binary-only X.Org graphics drivers currently aren't able to take advantage of this technology.

Following KMS, the second area with the most interest is seeing video improvements to X.Org and then DRI2 in a close third. When it comes to video playback improvements, the leading open-source solution right now is through XvMC, or X-Video Motion Compensation. XvMC though is of limited use these days and is not supported by all X.Org drivers. At this time XvMC only is able to offload MPEG-2 decoding to the GPU, but there has been talk of extending XvMC though that yet hasn't amounted to anything. Intel has also been behind the VA-API (Video Acceleration API), but that too has appeared stagnant.

The closed-source X.Org drivers have really been leading the pact when it comes to video playback acceleration with the recently introduced VDPAU (Video Decode and Presentation API for Unix) by NVIDIA and the XvBA (X-Video Bitstream Acceleration) that soon will be introduced by AMD in their Linux driver. VDPAU is a poster-child for great GPU video decoding with its support for H.264, WMV3, MPEG-2, and VC-1 formats and support for decoding, post-processing, compositing, and displaying compressed/uncompressed video streams. With a $20 CPU and $30 GPU we were even able to play HD videos on Linux with VDPAU while compiling the Linux kernel simultaneously.

At just over 20% interest, the Direct Rendering Infrastructure 2 with respondents. The design of DRI2 was hashed out at the X.Org Developers' Summit in 2007 and was close to being introduced in early 2008. DRI2 was made available in March of 2008 and was slated for introduction with X Server 1.5 / X.Org 7.4, but an invasive redesign to DRI2 caused the support to be dropped. DRI2 went through more revisions (one and two) and finally is being officially introduced with X Server 1.6 next month. DRI2 Direct Rendering is popular with users as it completes the puzzle in being able to have direct rendering to redirected windows in a composited environment.

Generating less interest among users was Gallium3D, Multi-Pointer X, and X Input 2. Gallium3D is the new 3D graphics architecture being developed by Tungsten Graphics (now owned by VMware) and Multi-Pointer X is the technology that allows for multiple input devices (such as having many keyboard and mice attached to one X Server) that is now postponed for introduction until X Server 1.7.

<< Previous Page
1
Latest Linux Hardware Reviews
  1. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  2. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  3. Ubuntu 14.10 XMir System Compositor Benchmarks
  4. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
Latest Linux News
  1. Fedora 21 Beta & Final Release Slip Further
  2. Mesa 10.3.2 Has A Couple Bug-Fixes
  3. RadeonSI/R600g HyperZ Support Gets Turned Back On
  4. openSUSE Factory & Tumbleweed Are Merging
  5. More Fedora Delays: Fedora 21 Beta Slips
  6. Mono Brings C# To The Unreal Engine 4
  7. Coreboot Now Has Support For Intel Broadwell Hardware
  8. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  9. GTK+ Lands Experimental Backend For Mir Display Server
  10. Ubuntu 14.10 Officially Released
Latest Forum Discussions
  1. HOPE: The Ease Of Python With The Speed Of C++
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  4. Linux hacker compares Solaris kernel code:
  5. Advertisements On Phoronix
  6. Users/Developers Threatening Fork Of Debian GNU/Linux
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed