Hardware acceleration using OpenGL and X11
 

Hi! Is there anyone who can explain how OpenGL acceleration works on Linux and its relationship with X11?

I read about modules like GLX, DRI, DRM and Gallium and I understand they are necessary to provide performance as the current structure of X11 makes it difficult to render efficiently. Is this correct?

If I use the OpenGL and EGL drivers provided by the manufacturer of hardware on X11 without any other module, should I expect, even with hardware acceleration a high CPU load? The modules GLX, DRI, DRM etc... can be used with any OpenGL implementations or only with mesa?

Thanks for many info! There is a hell of concepts here and I'm quite confused.

The OpenGL standard is an API defining an abstract 3D language (the other common API being Microsoft's Direct3D). Since the X11 standard was much earlier, it has no 3D features, so OpenGL has become the common way of providing these.

Since we want to have 3D within X11 windows, there has to be a way for OpenGL implementations to operate underneath X11. GLX provides extensions to X11 to provide this functionality, ie taking client OpenGL calls and passing them on to the OpenGL libraries, which can also involve encapsulating these commands to be passed across a network connection.

Mesa3D is an free/libre implementation of the OpenGL standard. It takes OpenGL calls, and passes them on to appropriate rendering libraries. Initially it was a software library, ie, using the CPU to do the rendering (not accelerated), which meant that OpenGL applications could be run on most hardware. Since then, support for GPU accelerated drivers has been added.

The DRI driver is used by Mesa3D for this GPU accelerated rendering. DRI is an infrastructure that coordinates the direct access to the hardware required for this accelerated rendering (both direct memory access and GPU access).

The evolution of Mesa has resulted in the development of Gallium3D (now a part of the whole Mesa project). The Gallium library is effectively a refactoring of the Mesa system, to capitalize on commonalities between different graphics cards. Under Gallium, the DRI has been separated into two parts, DRM to handle the direct access to memory, and DRI2 to handle direct access to the GPU acceleration. Because Gallium provides an abstract low level graphics API to the drivers, the implementation of the connection between OpenGL and the low level API is now consistent between graphics cards.

So to answer your questions, if you are running OpenGL applications under X11, you will normally be using GLX to manage the 3D commands, and Mesa/Gallium to implement them, no matter what underlying acceleration you have (if any). Below that will be the drivers from the manufacturers. If your graphics is being hardware accelerated, you should see a substantial reduction in CPU load; though this will depend on the application (for example, a lot of physics simulation in games is still done on the CPU). The program glxinfo (part of the mesa-utils package) is useful for determining what acceleration your OpenGL implementation is providing.

I'm still studying your message because it is full of information. Very useful for anyone trying to understand a little bit about this.

Just to help me understanding the entire architecture, there is something which is not quite clear to me: in all this, what are the elements that are hardware related and that should be provided, in general, by the manufacturer?

In the final part of your message I understand that this entire architecture (X11, DRM, DRI2 and GLX or EGL) is independent on the hardware. Is this correct? "Below that" specific OpenGL libraries will be placed and Mesa/Gallium will use those specific OpenGL libraries. Is this correct?

In my Ubuntu for instance I have enabled the proprietary ATI drivers. This means, if I understood correctly, that Gallium is using DRM to manage memory, DRI2 to give direct access to the acceleration provided by OpenGL specific implementation (ATI OpenGL implementation). Mesa3D is not needed because I'm using another OpenGL implementation.

Another question is: I see that DRM in the kernel has AGP as a prerequisite. What about integrated GPUs not using AGP?

Thank you very much for your explanations!

The hardware dependent modules are not separate parts of the architecture, but are components of some layers (primarily the DRM/DRI layer).

The DRM/DRI layer contains both device independent and device specific modules (/lib/modules/…/kernel/drivers/gpu/drm/* and /usr/lib/dri/), and even the X11 architecture without the GL extensions has device specific 2D rendering modules (ie, DDX drivers in /usr/lib/xorg/modules/drivers/).

There is no reason why integrated GPUs cannot make use of the common DRM module (although they won't need the AGP routines). The common DRM module provides some core functionality, to simplify writing the device specific DRM modules.

Of course, you will find that some proprietary driver sets do not use even the device independent modules, and provide their own implementations of the OpenGL components. They won't necessarily split things up in the same way that Mesa/Gallium does.

So, as a summary, the "chain" is something like MyApplication -> EGL (or GLX) -> OpenGL -> X11 (bypassed by DRI2 to avoid excessive X11 computation) -> DRM -> Framebuffer -> Display.

And for a specific hardware, it may be necessary for a GPU manufacturer to provide an implementation of OpenGL (or OpenGL ES x.y), an implementation of EGL for X11 and some modules for the Direct Rendering in both DRI2 and DRM.

Am I completely off the way or am I learning something? :-)
And all this architecture is subject to modifications when talking about OpenGL ES 1.x or 2.0? I read somewhere that DRI is no longer supported with OpenGL ES.

Thanks very much for you clarification!

Pretty much. I would think of DRM as more a resource manager that ensures that DRI access to the hardware does not interfere with the rest of X (rather than DRM as another layer). And when it is being accelerated, the framebuffer generation is of course being done by the GPU rather than the CPU.

As a minimum, specific hardware requires a DRM module, a DRI backend to Mesa/Gallium, and a DDX module (eg this is how the Nouveau driver works). There is no need to implement the OpenGL API, just the DRI API. However, some proprietary drivers replace the usual modules (eg Nvidia replaces GLX and Mesa and does their own resource management).

Yes, the architecture is going to vary between different implementations of OpenGL. Still, you will have the basic structure of an X system, the OpenGL implementation, the X extensions to call into the OpenGL (such as GLX or EGL), and some sort of backend so the OpenGL code can talk to directly to the hardware.

Likewise, switching from X to Wayland involves some changes to the overall architecture.

This is very interesting again. I can't understand something: in my notebook I have a Ubuntu Linux, with hardware acceleration and DRI enabled (glxinfo reports this). The GPU seems to be an ATI.
Question is: does this mean in my Ubuntu I have a DRM module, a DRI backend and this DDX module for my arch?

Another question (sorry for these many questions but there are only few people who can answer these questions it seems): I see that in my Ubuntu I can enable proprietary drivers or disable those. I came up disabling because performance seemed to be better. What does this mean? That opensource implementations of OpenGL, DRM, DRI etc... perform better than ATI's? How is this possible?

Again, thanks for the useful information.

If you have a look in /var/log/Xorg.0.log, you will get some idea of which X drivers are being loaded for your card. For an ATI GPU, I'd be guessing you will have the radeon.ko kernel module, one of the radeon dri backends (perhaps radeon_dri.so or rXXX_dri.so), and the radeonhd_drv.so Xorg driver.

AMD (who bought out ATI) have been contributing free drivers to Linux for some time now, and they are fairly stable. It may be that the proprietary fglrx drivers are dated, and perhaps don't perform as well (or are primarily useful for specific cards that are not supported by the newer free drivers). The situation is different for Nvidia cards, where the free community written nouveau driver does not yet have all the functionality of the proprietary drivers.