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

BSDs Struggle With Open-Source Graphics Drivers

BSD

Published on 08 February 2013 08:51 AM EST
Written by Michael Larabel in BSD
114 Comments

While there's plenty of code pouring into the Linux world for bettering open-source graphics drivers from desktop graphics cards to ARM SoCs, in the *BSD world they are struggling with their graphics driver support. Matthieu Herrb gave a presentation on the (rather poor) state of graphics on Unix-like platforms outside of Linux.

Matthieu Herrb, a long-time BSD developer and X.Org Foundation member, presented last weekend at FOSDEM 2013 about the BSD graphics support.

As talked about in many Phoronix articles in recent years, and should be no surprise to any graphics/X.Org enthusiasts, changes in how Linux graphics drivers (and X.Org itself) are developed have led to the downfall on non-Linux systems. Traditionally with the X11/X.Org Server being multi-platform and the DDX drivers controlling the hardware while running in user-space, it hasn't been hard to maintain graphics card support between Linux, *BSD, and Solaris. However, with kernel mode-setting and DRM being the standard expectation now, non-Linux platforms lose out.

The KMS/DRM drivers living within the Linux kernel are often permissively licensed compared to the GPL, which isn't the problem but that these kernel drivers are designed around Linux interfaces. Even porting the TTM memory manager to non-Linux kernels has proved to be difficult for BSD developers.

With open-source graphics driver developers working around Linux as their primary platform (and often not caring about other platforms), it's difficult for other developers to maintain pace in porting over the driver support. It took years for FreeBSD to support Intel KMS, which only happened in mainline a few months back with the FreeBSD 9.1 release. There's still no mainline Nouveau and Radeon kernel drivers for FreeBSD due to the major work involved. The other BSDs are in similar standing or even worse off without a port of any Linux KMS driver.

Oracle Solaris has modern Intel kernel mode-setting support with Solaris 11 and Solaris 12 might have a Radeon KMS driver, but that's really it in the Solaris world. Illumos/OpenIndiana as the independent/community Solaris spins have no mainline KMS support.

For providing support for modern Intel graphics cores, OpenBSD developers ended up porting the Ironlake and Sandy Bridge chipset support to an old xf86-video-intel DDX driver with user-space mode-setting. Intel dropped their UMS support years ago while OpenBSD is maintaining an old pre-UMS-dropping X.Org driver where they have been meticulously back-porting new Intel hardware support. The OpenBSD 5.3 release in a few months will have Intel Ivy Bridge support, one year after the hardware debuted. There is on-going work for supporting Intel KMS on OpenBSD. Another shortcoming of OpenBSD is no multi-touch support.

The NetBSD operating system does have a GEM implementation, but it's currently living in GitHub and not in mainline. The operating system is making slow progress on KMS.

DragonFlyBSD did get some work done as part of Google Summer of Code for GEM/DRM/KMS, but nothing that's in real good standing.

Matthieu Herrb summarizes the current situation for non-Linux systems as "lagging behind" with the biggest issues being new X.Org Servers requiring newer drivers, newer drivers requiring newer DRM (kernel support), and the kernel drivers being harder to port to BSD/Solaris. The push for moving more of the graphics drivers into the kernel is good for Linux, but real bad for the *BSDs.

Multi-touch support for the BSD operating systems is also quite bad overall with input drivers frequently being in the kernel rather than xf86-input drivers.

Wayland will also be a mess for BSD and Solaris operating systems due to its dependence on kernel mode-setting, kernel input drivers, and Weston being designed with solely Linux in mind.

Matthieu concluded his FOSDEM talk by saying there's tough times for non-Linux systems, there is progress and little hope, and help is needed for overcoming major hurdles. Herrb has posted his slides on the X.Org Wiki.

Latest Linux Hardware Reviews
  1. Mini-Box M350: A Simple, Affordable Mini-ITX Case
  2. Overclocking The AMD AM1 Athlon & Sempron APUs
  3. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  4. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
Latest Linux Articles
  1. A Quick Look At GCC 4.9 vs. LLVM Clang 3.5
  2. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
  3. AMD Athlon's R3 Graphics: RadeonSI Gallium3D vs. Catalyst
  4. GCC 4.9 Compiler Optimization Benchmarks For Faster Binaries
Latest Linux News
  1. Fedora 21 Gets GNOME 3.12, PHP 5.6, Mono 3.4
  2. Fedora Workstation Is Making Me Quite Excited
  3. Maynard: A Lightweight Wayland Desktop
  4. Chromium Browser Going Through Growing Pains In Ubuntu 14.04
  5. KDE 4.13 Is Being Released Today With New Features
  6. Trying Out Radeon R9 290 Graphics On Open-Source
  7. Intel Broadwell GT3 Graphics Have Dual BSD Rings
  8. Early Linux 3.15 Benchmarks Of Intel Core i7 + Radeon
  9. Red Hat Releases Its RHEL 7 Release Candidate
  10. New Features Coming To Xubuntu 14.04 LTS
  11. NVIDIA Officially Releases CUDA 6
  12. Google Releases An AutoFDO Converter For Perf In LLVM
Latest Forum Discussions
  1. The GNOME Foundation Is Running Short On Money
  2. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  3. Change installation destination from home directory
  4. After Jack Keane, RuseSoft will briing Ankh 3 to Linux through Desura
  5. Bye bye BSD, Hello Linux: A Sys Admin's Story
  6. New tool for undervolt/overclock AMD K8L and K10 processors
  7. How to enable opengl 3.3 on r9 270?
  8. R290x sound problems