No announcement yet.

Gallium3d, DRI, Mesa, Xorg?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Gallium3d, DRI, Mesa, Xorg?

    I guess you can say that I am a little confused. I have heard of all these terms and components, But I'm having a difficult time picturing how they fit together, and what purpose they serve.

    Lets start with Xorg. uuummmm??? This is easily the most confusing piece of software I've ever seen n my life. It appears at first to be a mish mash of totally unrelated components that should have it's own service, but instead are rolled into one package called xorg.It is apparently an implementation of the X11 protocol that was forked from something called xfree86. What is x11? And how come it handles graphics drivers and not the kernel? If it's a display server why does it control keyboards, mice and joysticks? Shouldn't those devices be handled by the kernel instead?

    Then moving on to DRI. This one makes sense.. Direct Rendering Manager.... Obviously it is responsible for rendering graphics. My question is why is it that it is only used for rendering 3D? Shouldn't it be used for all rendering?

    Then there is Gallium3D. Something new that is supposedly going to replace DRI? But why?

    And Mesa? An OpenGL implementation under the GPL. Why doesn't ATi, and nVidia use this instead of using there own implementation? And why does it exist in the first place? isn't that what DRI is for?

    Sorry for all the stupid questions, and total lack of understanding. I know you guys prolly get annoyed by all the noobs hounding you. I appreciate all the help, if you can help a poor noob understand better it'll be greatly appreciated. Thanks guys.

  • #2
    A good description of the X windowing system is found here:
    A quote is here:
    X provides the basic framework, or primitives, for building GUI environments: drawing and moving windows on the screen and interacting with a mouse and/or keyboard. X does not mandate the user interface ? individual client programs handle this. As such, the visual styling of X-based environments varies greatly; different programs may present radically different interfaces. X is not an integral part of the operating system; instead, it is built as an additional application layer on top of the operating system kernel.

    XFree86 was an implementation of the X11 Windowing system. The XFree project faded away when companies like HP and Sun put resources into the foundation which took over XFree's role as the predominant Linux X11 windowing system.

    The drivers are handled in Linux as kernel modules. Modules can be dynamically linked into the kernel at run-time. X11 simply uses these drivers to accomplish its goals as a windowing system.

    And as far as why X11 does stuff with Keyboards and mice, etc.. it's probably because making a subsystem of a system covering I/O makes more sense than one dealing with Output and one with Input.

    As far as the technically-oriented questions to why DRM doesn't render all graphics I'd refer that to one of the driver developers that float around here.

    From my interpretation DRM is a interface to the hardware of the GPU on the system. It is an abstraction to access the hardware of a particular card.

    Mesa is like you said a GPL'ed openGL implementation for Linux. Part of mesa's libGL are a set of mesa_DRI drivers that use DRM to provide openGL hardware acceleration so a given application(say tuxracer) can run using GPU acceleration. Without a DRI driver (or DRM) mesa would resort to indirect(CPU-based) rendering which slow.

    Mesa exists because it was written for the plethora of 3d cards that are supported with open source drivers.

    ATI and Nvidia don't use it in their respective proprietary drivers because, it being licensed under the MIT license, isn't applicable for there models. (I believe that'd be why I am not a lawyer though...) if that isn't the reason then I don't know.

    Most of this is from an amatuar's prospective so if any of it is incorrect/misguided don't feel bad correcting it.


    • #3
      Here's my 2 cents.

      X11 is the 11th major revision of the X windowing system. I believe it includes mice, keyboards etc. because input from those devices is intimately tied in with the windowing since input events need to be fed to whatever application owns the window where the input is directed -- and only the windowing system knows that.

      Xorg is the group of people who manage the direction of the most common implementation of the X windowing system -- also, confusingly, called Xorg. In general "xorg" refers the windowing system while "" refers to the people.

      The X protocol was designed around "indirect rendering", where the application could be on one computer, the display server on another computer, and all user I/O was routed through the X11 protocol. The downside of this is that there is some overhead from the protocol, although it's apparently pretty tiny these days.

      3d rendering can be done in (at least) two ways -- "indirect" trough the same X protocol as text and 2d graphics, or "direct" which bypasses the X protocol and lets the application talk directly to the graphics driver.

      Most of the X driver code actually runs in user mode and accesses hardware by getting generous privileges from the OS. DRM is a "kernel component" for graphics which was, I believe, originally developed as part of the Direct Rendering Infrastructure initiative. It mostly handles the really performance-critical work associated with pushing commands into graphics chips, getting results back, and deciding what to do next. Since it was developed as part of the 3d DRI initiative

      DRM was initially only used for 3d rendering, but increasingly DRM is becoming a general component used by 2d, 3d and video rendering.

      Mesa is an implementation of a 3d GL stack, and is the standard for pretty much all open source 3d graphics. AFAIK it is still not strictly considered "OpenGL" because it does not include compliance with the (relatively expensive) OpenGL validation suite as one of its requirements. I forget the details, but basically the Mesa developers would have had to pay a bunch more money to officially use the OpenGL name.

      Mesa was written as a pure software renderer at first, then added acceleration at a time when most high performance graphics chips implemented a programming model similar to "the openGL pipeline", ie a fairly well defined transform, clipping, lighting and rendering pipeline. Since then, graphics chips have evolved into much more general purpose parts with large numbers of parallel processors generically called "shaders". This is IMO partly because of the influence of DirectX and partly because process shrinks allowed much higher transistor counts so fixed function blocks could be replaced with larger but more versatile programmable blocks.

      Over the last 10-odd years, the major GPU vendors moved to 3d driver architectures which were better suited for modern GPU designs and could extract the most performance from those chips.

      Similarly, Gallium is a proposed new architecture for the Mesa 3d driver, taking it from a very traditional to a very modern design. So far the new architecture looks very good.

      One abbreviation you didn't mention, but is pretty important, is "TTM". The abbreviation originally stood for "translation table maps" but has kinda become a proposed standard for memory management in the DRM code, allowing all video memory to be managed in the kernel code rather than by the X server as it is today. Good and flexible memory management is one of the keys to making a high performance 3d driver, so as I understand it getting TTM into DRM is one of the pre-requisites for rolling Gallium out into production. I'm not sure about this last point but that's the way it looks.

      In order to get a complete display system running, you need the X server (xorg), an X driver (eg radeonhd), a DRM driver and Mesa. If you look at the source code on, you'll see that each different X driver has its own tree, while DRM and Mesa each only have one tree each with per-chip drivers buried further down the tree.

      Hope things aren't even more confusing now
      Last edited by bridgman; 01-03-2008, 10:13 PM.


      • #4
        nice, thanks for the info


        • #5
          Originally posted by bridgman View Post
          Here's my 2 cents.
          Whoa... A lot of value from that 2 cents' worth, that.


          • #6
            Oh strikes me that John's post #3 in this thread is a wonderfully concise and cogent explanation of the Linux video subsystem. Would you consider making it a sticky somewhere so it would be available for future reference?


            • #7
              btw it's the kernel that manages all devices, including keyboards and mice. nobody said [but the original poster suggested] you can't use them outside of X .


              • #8
                Originally posted by yoshi314 View Post
                btw it's the kernel that manages all devices, including keyboards and mice. nobody said [but the original poster suggested] you can't use them outside of X .
                Not exactly. Most X video drivers (and quite a few input drivers) are implemented completely in userspace right now. This was a vestige of xfree86 and multi-OS compatibility. Some video drivers make use of a kernel drm module for hw arbitration for 2D/3D rendering, but most of the setup still happens in the ddx (userspace X driver). With drm modesetting and ttm, most of the ddx functionality moves to the kernel.
                Last edited by agd5f; 01-04-2008, 02:35 AM.


                • #9
                  Originally posted by rbmorse View Post
                  Oh strikes me that John's post #3 in this thread is a wonderfully concise and cogent explanation of the Linux video subsystem. Would you consider making it a sticky somewhere so it would be available for future reference?

                  Michael Larabel