Graphics Pipeline

I am giving a tuorial on using GL/extensions/Mesa in an interchangeable fashion. I tried to put together a flowchart on how commands flow through the libraries/devices, and at which point extensions are processed. I need some expert opinion on the attached graphic. I was unsure of the interaction between the graphics driver and X. Same goes for Mesa3D and X.

There is no attached graphic?

Sorry about the graphic. I edited the post to include it.

I believe Mesa3D processes the extensions before sending commands to X. The graphic should have a single arrow between Mesa and X, not all 4.

And Mesa3D does include some accelerated card drivers (intel, matrox, 3DFX, savage ). Check DRI.

And the separation between OpenGL and the video driver is not really present in the hardware accelerated case.

Personally, I would remove X from that diagram, as that is not a necessary component. Perhaps it should be replaced by a generic kind of “Window Manager” construct that is platform dependent.

And the separation between OpenGL and the video driver is not really present in the hardware accelerated case.
It is how GL is implemented in practice. OpenGL implementations are divided into a client side and a driver side part. The client side calls into the driver side, based on activity from the driver (if the driver’s FIFO buffer get’s low, the client can be notified to add stuff to it) or the user code (if the user asks to draw something).

I think I will leave the seperation of OpenGL and the driver. At what point are the extensions interpreted, GL or driver? I think it may vary depending on the extension. Is this true?

I think I will rename the “X” box to “DRI XFree86/” to show that it is the driver core for some drivers. I will also add a direct line from Mesa3D to the Graphics card for pure stand-alone Mesa implementations.

Does this seem to make sense?

Here is the new graphic. Does this pass the test?

You have separated OpenGL and Graphics Driver. I don’t think that’s correct. When you call a GL function you’re directly talking to the OpenGL Graphics Driver… ie. they’re not separate AFAIK.


Well, that really depends on the implementation. If you need to support multiple drivers running simultaneously , then you’ll want to separate the GL framework from the drivers and make code common where possible.

The driver is seperate. If I change my graphics driver, I also have to upgrade my GL library as well. Although they are tightly coupled, they are not one in the same. It was designed this way to support render farms that would pass commands on to a high performance rendering machine. For example, try running a GL application remotely. You can export the display and run a binary from another system. That binary does not use your library since it is on another system. Yet, it will utilize your graphics card and display the resulting image to your monitor.

One other thought. If you have a Windows machine, your graphics card can most likely run both GL and DirectX. There are not two seperate drivers for the card. There is only one way to talk to the card. The GL library is responible for taking the GL API and translating for the driver.

I’m not sure about the separation between OpenGL and Mesa3D. I think this is misleading in your graphic, because it suggests that both are present, while this does not make sense in practice.

On windows, you have the following picture:

        | core 1.1             |
        v                      |
GL library (from MS)           | extensions + core >= 1.2
        |                      |
        v                      v
               GPU driver

On Linux with DRI, Mesa3D replaces the GL library and the DRI driver replaces the ICD, and the extensions are also handled by Mesa3D. X is bypassed.

On Linux with sofware rendering, Mesa3D directly communicates with X (Mesa->X->driver).

On Linux with nVidia cards, there is no Mesa. The GL library from nVidia directly communicates with the driver.

I am actually going to talk about using both at the same time. Mesa can be compiled with name mangling so that glFunction turns into mglFunction. This allows you to use Mesa as a fallback if the GL implementation doesn’t support your feature. You just have to distribute Mesa with your software.