OpenBSD Journal

DRI - Developer interview with Owain Ainsworth

Contributed by mitja on from the not-the-evil-kind-of-DRM dept.

Those of you that follow OpenBSD development closely will have noticed a steady stream of updates in the X Window System in the last year, specifically related to hardware accelerated graphics rendering. In this edition of Undeadly developer interviews, meet the man behind it - Owain Ainsworth (oga@).

OpenBSD Journal: First, tell us about you - how did you become involved in DRI and OpenBSD development in general?

Owain Ainsworth: Well, I started using 'nix in 2004 during my second year of university, with Slackware Linux. A while later (just before 3.8 was released), I got a Zaurus. Looking for a "full" unix environment there, and unsatisfied with the available solutions, I decided to give that OpenBSD thing a try. I fell in love with the simplicity and coherency of the system, and soon changed my other machines over too.

I've always hated it when things didn't work, I hate having hardware that's not being used when it could be. I remember the first time I had to get DRI working on an old Radeon integrated into one of my old laptops - it was hellish! When I migrated to OpenBSD, I was somewhat annoyed that the OS didn't support DRI, since I was mostly a desktop user, and using video hardware properly seemed like a good idea. Having heard about the "shut up and hack" attitude, I figured that if no one else did it, I'd might as well have a try. Fast forward a year or two - I spoke to Matthieu Herrb (matthieu@), asking him if anyone was working on it, and received a reply to the negative; I mentioned I would be interested in trying my hand at it when I found some time.

Fast forward another year. I'd just finished my undergraduate fourth year project in visualisation. This involved using OpenGL a fair amount and I did the whole thing on OpenBSD (yes, with software rendering). While waiting to hear if my proposal for a PhD has been accepted, I realised I was running out of excuses and ought to seriously look at porting DRI support to OpenBSD.

The last straw was seeing that NetBSD committed DRI support to their kernel, making OpenBSD the only one of the three major BSDs without such support. I thought this had to change. At this point I had no experience with kernel programming past a short course in ARM assembler during uni, and some work with an AVR microprocessor at around the same time. After a lot of discussion with art@, matthieu@ and miod@ things started to take shape, and I was offered an account and an invite to the h2k7 hardware hackathon in Coimbra, Portugal. The rest, as they say, is history.

OJ: You are using the acronym DRI and I've seen DRM mentioned elsewhere - let's get our terms straight, what is the difference between DRI and DRM? How does it all fit together?

oga: DRI is an acronym for the "Direct Rendering Infrastructure", an extension to the X11 protocol to enable 3D hardware acceleration for xfree86, and later

This is comprised of several parts: The X DRI extension, which handles the proctol parts of the system. Some code in the DDX (Device Dependent X, the hardware drivers) to setup the hardware for this. Kernel parts, namely the Direct Rendering Manager (DRM), which controls access to the hardware and DMA, and the OpenGL drivers, which are part of the Mesa3D project, which translate OpenGL commands into the appropriate hardware command stream.

OJ: Why is DRI so complex?

oga: Let me start at the basics: X thinks it is an LKM. When X was initially ported to the x86 architecture back in the early 90s, there was no portable way of performing the hardware access that it needed to do, such as enumerating the PCI bus to scan for hardware, and accessing hardware registers. It is for this reason that X traditionally maps /dev/mem in order to perform these operations manually. OpenBSD attempted to take measures against this with the xf86(4) aperture driver, that restricts the addresses that X can access somewhat. Recent versions of the xserver (1.5, particularly) use libpciaccess to alleviate this a bit, by using OS-specific interfaces for accessing PCI space. With the addition of direct rendering - where an application sends gl commands to hardware directly, as opposed to via the X server, since otherwise memcpy overhead is huge - some attempt at security was needed. In addition, userland (reasonably) has no way with which to obtain a DMA-usable address for memory. Therefore the DRM was needed to provide and manage access to these services in a "sane" way.

However, current methods for that are still imperfect. In order to control access to the hardware ringbuffer - which both the userland DDX and the kernelside DRM needed to touch - the DRM currently has a lock between userland and kernel, it's horrid! The need to synchronise some data also lead to a userland/kernel shared area (SAREA). Earlier interfaces were even worse. They tried to pass IRQs to userland via the xserver's SIGIO handler on the DRM file descriptor. Luckily that is no longer the case.

Finally, if the previous wasn't enough, there are currently several managers for graphics memory. One in the DDX, for memory used for pixmaps and other 2D resources, a second very trivial one in the DRM to provide access for DMA memory, and further code in mesa to handle texture memory layout. The only sane way with which to solve this is to have graphics memory entirely managed by the kernel, with the various competing applications requesting space as needed.

The first try at such a system was the "TTM" memory manager API, designed by Thomas Hellström at Tungsten Graphics. More recently, a differing API, the GEM (Graphics Execution Manager) was developed by Keith Packard and Eric Anhold at Intel due to the poor performance they had found in writing a TTM based driver.

The GEM model is a lot less complex in this manner. In such setups, the ring buffer is entirely handled by the kernel (as it should be), with userland allowed to supply Indirect or "Batch" buffers to be executed by the hardware. On Intel hardware, at least, Batchbuffers are executed with a flag labelling them as nonsecure, this prevents the use of some hardware commands.

This isn't the whole story, since the WIP GEM driver for radeon hardware actually uses the TTM under the hood, since it deals correctly with migrating memory to and from Video RAM. Intel does not need this since Intel hardware is UMA (Unified Memory Architecture), where all memory used by the graphics card is system memory.

OJ: What are the benefits of this DRI/DRM infrastructure to a common user? What does he gain from it?

oga: Historically, the only benefit was faster 3D. Which is nice for gamers and people working with CAD or visualisation. However, in more recent times, due to the fact that newer video hardware has less and less circuitry dedicated to handling 2D tasks and the bulk of it being either directed at 3D or (with very modern hardware) fully programmable, some drivers (notably the radeon driver) have taken to using the 3D pipeline on graphics cards to accelerate 2D rendering too. As an example, with EXA as the acceleration architecture, the radeon driver runs a lot faster if the DRM module is enabled in the kernel then without.

On the more futuristic scale, other benefits are on the horizon, specifically kernel level modesetting, which would eventually allow the X server to run as a normal user with machdep.allowaperture set to zero.

OJ: It has been a year since you started working on DRI - can you see the light at the end of the tunnel yet?

oga: Dimly and far off, but yes. Thing have definitely improved by orders of magnitude from this time last year, when I was literally just starting. Nowadays, we have close-to bug parity with other OS' DRM drivers, with only a few known disparities. The intel and radeon drivers -- which have obtained the most interest -- now work on the vast majority of hardware claimed to be supported. The other drivers, for SiS, Matrox, ATI Rage 128, ATI Mach 64 and S3 Savage have had less attention, though at least ragedrm and sisdrm have been reported to work.

There's unfortunately still an awful lot of work to be done. Recently I have mostly focused on code cleanup, specifically on making the DRM drivers more BSD-like, since the code definitely shows their Linux heritage. As well as this ongoing cleanup work and the obvious bug fixes, two main hurdles remain:

Firstly is the porting/implementation of memory management. The GEM driver, I'm told is planned to be shipped in Linux 2.6.28 (2.6.27 was just released), showing Intel's confidence in the API. I've completed a by-the-numbers port, which is doubtless buggy since it has not been tested, due to my lacking the time to set up an xserver 1.5 environment with the suitable userland parts to leverage it. Once this kinda works, there will be a lot of re-engineering to carry out to make the internals mesh properly with our kernel.

Secondly is the design and implementation of a kernel modesetting interface, where setting a graphics mode (such as 1024x768, 60Hz refresh, 24 bits per pixel) is carried out by the kernel and not by the Xserver in userland as it is currently. This has to interface closely with wscons, as well as the rest of the kernel.

OJ: Still, the OpenBSD 4.4 release is just around the corner, how much of DRI will be usable with this release? Is it enabled by default? What drivers are supported?

oga: Good news maturity-wise is that the 4.4 release ships with the intel and radeon DRM drivers compiled into the kernel, but disabled by default, a similar situation to ACPI a few releases ago. The code in the 4.4 release is also fairly complete feature-wise. When enabled, Radeon 2D performance will increase significantly when using the EXA architecture. 3D support also works well, with several people expressing enjoyment of games such as the experimental port of openarena (which unfortunately did not make the release).

OJ: So, how do we test it and report?

oga: On a 4.4 machine to test the DRI support is quite simple:

1) boot -c
2) enable {inteldrm,radeondrm} (whichever you need to use)
3) quit
4) let it finish booting and startx
5) if it works, you may make this permanent using config -ef /bsd

On -current, inteldrm and radeondrm are now enabled by default, so all you have to do is startx.

When you're in X, to confirm that everything has enabled correctly use the glxinfo command, and check the renderer string. An increase in the speed of the world's worst benchmark, glxgears(1), also helps prove to yourself.

If you find a problem? First, upgrade to -current or a snapshot and test if the issue has been fixed there (I will IGNORE bug reports that miss out this step). Second, either email me (oga@) or use sendbug with all the information provided in and a complete description of the issue, including your Xorg.log.

CAVEATS: there are known issues with the RS4XX (Radeon Xpress 200m) and RS690 chipsets. A fix for this is being worked on, but is not in 4.4, so they will not work. Also Radeon support is for chipsets of R400 (the X800) class and below, the mesa version shipped with 4.4 does not include support for R500 chipsets. They are included in mesa 7.1 which is currently being worked on by Matthieu, and will hopefully be available for -current testing soon.

If you happen to have hardware supported by the less tested DRM drivers, please enable them in your kernel config (they are commented out in GENERIC), and provide me with your test results.

OJ: How can we help further? Do you have all the hardware and documentation that you need?

oga: Well, I always appreciate testing for a start! Documentation is always a thorny issue, though things do appear to be improving: Intel released the documentation to their 965 chipsets a few months ago, and AMD have very publicly released documentation for the R500 chipsets (enabling the mesa support previously mentioned), they also claim to be finalising the legal matters around releasing documentation for the later R600 chips. Any documentation for any other hardware that is available is always appreciated.

Hardware wise, I have samples of several bits of ATI and Intel hardware, and some of the other lesser drivers. If anyone has any of the following they would part with, I'd appreciate it:

  • Any spare AGP-capable machines lying around (mine have a horrible habit of dying, right now I have none)
  • I have a few radeon cards (9200SE, AGP x1950, PCIE x800se), but any spare cards lying around that aren't those would be good for testing
  • More difficult, but the loan of a laptop with an XPress 200m would be excellent. I know they don't work at all, but I can't manage to debug it remotely (PR5901)
  • Matrox AGP cards, I have none, and no idea if the driver works
  • ATI Mach64 cards
  • Anything from the S3 Savage or Supersavage range
  • Let's thank Owain for the effort he has put into making DRI a reality and for taking his time to answer our questions in such detail. The hardware he is asking for is essential for extending the DRI infrastructure to those devices and their drivers - so if you would like to see it happen, help oga@ get the hardware he needs!

    (Comments are closed)

    1. By Anonymous Coward ( on

      Great work on the DRI.

      I've been waiting to see some news about the DRI situation for a while and here it is :)

      If I can sqeeze OpenBSD on my desktop I will test the DRI on my new Intel card to see how it works. If it performs well I might convert my desktop to OpenBSD which would be great.

    2. By niallo ( on

      I'm super impressed with the DRI work thats gone into OpenBSD lately. I just updated the snap on my laptop today and, with no configuration, I get OpenGL acceleration in hardware.

      This is way simpler than Windows and Linux. It seems to "just work". I know people who waste days with dodgy Linux binary-only drivers and end up with an X configuration that crashes all the time.

      Fantastic work. Thanks so much.

    3. By Anonymous Coward ( on

      Thanks a lot for your work.

    4. By Anonymous Coward ( on

      Thank you VERY much for your work on DRI. It is really working great on my Intel-based laptops and ATI x300 card in my desktop machine. It is so great to see how OpenBSD development occurs behind the scenes. Thank you for sharing your story, Owain, and thanks to for publishing the interview!

    5. By Anonymous Coward ( on

      Nice job on DRI.

      I wonder how long it will take until we see compositing desktop managers in the ports.

      1. By Brad (2001:470:8802:3:20f:b5ff:fe45:7cfe) brad at comstyle dot com on

        > Nice job on DRI.
        > I wonder how long it will take until we see compositing desktop managers in the ports.

        There already are. DRI is not required to do compositing.

        1. By Anonymous Coward ( on

          > There already are. DRI is not required to do compositing.

          Isn't the DRI needed for hardware accelerated compositing?

          I'm aware that kwin and xfwm and probably a few other window managers have some low-end compositing features that are rendered in software, but for the more juicy effects and also for overcoming the painfully slow 2d rendering of X, DRI is a prerequisite afaik.

    6. By Jona Joachim ( on

      I'd also like to thank you very much for your great work on DRI. I follow the
      CVS commits regularly and I'm quite impressed how much work you put into this.
      I'm using EXA with my R5** card for some time now without any trouble and I'll
      certainly test 3D as soon as the new Mesa is imported.

    7. By Alvaro ( on

      Please, 3d Aceleration in Nvidia cards
      6xxx/7xxx/8xxx at -


    Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]