Except OpenGL, I never used those libraries, but I’m going to try to guess, by reading wikipedia pages, like you did.

You seem right about Mesa. Here is the additional info we have :

“The X window system is a computer software system and network protocol that provides a basis GUIs for networked computers. It creates a hardware abstraction layer.”

“GLX enables programs wishing to use OpenGL to do so within a window provided by the X Window System.
GLX consists of three parts:
– An API that provides OpenGL functions.
– An extension of the X protocol, which allows the client to send 3D rendering commands
– An extension of the X server that receives the rendering commands from the client and passes them on to the installed OpenGL library
If client and server are running on the same computer and an accelerated 3D graphics card is available, the former two components can be bypassed by DRI. The client program is then allowed to directly access the graphics hardware.”

“Direct Rendering Infrastructure (DRI) is an interface used in the X Window System to allow user applications to access the video hardware without requiring data to be passed through the X server.”

“Open Inventor is a C++ 3D graphics API designed to provide a higher layer of programming for OpenGL”

To make things simpler, let’s imagine a simplified flow of data (and commands) that happens at the entries and exits of each of those APIs. At the very beginning we have your application program (compiled code), that you run from your computer. At the end we have images that are displayed on your screen.

There are several cases which I will restrain to the answers to these questions:
-does your computer have a graphic card (GPU), or only a CPU, to process graphic functions ?
-is your application embedded in a window of the x-window system ?
-if you use the x window system, is the “x server” running on your computer or on an other computer on the network ?
I’ll assume you have the drivers for your GPU if you have one, and that you have Mesa for the software rendering).

First scenario : you run a graphic application written with OpenInventor, without using to the X Window System, and you don’t have a graphic card. The program flow would be quite similar to :

Your application
  ↓ (uses functions of)
OpenInventor
  ↓ (calls functions declared by)
OpenGL
  ↓ (redirects function calls to implementation defined by)
Mesa
  ↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
  ↓
3D Images on your screen

What happens here is called “software rendering” : the graphics command are not handled by any graphic hardware, but instead by your usual CPU, the processor that generally runs software.

Second scenario : now imagine that with the same conditions as above, you have a graphic card. The flow would look more like this :

Your application
  ↓ (uses functions of)
OpenInventor
  ↓ (calls functions declared by)
OpenGL
  ↓ (redirects function calls to implementation defined by)
Proprietary Drivers
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

What happens now is called “hardware acceleration”, usually faster than the first scenario.

Third scenario : now let’s introduce the X Window System flow, or at least how I think it is, based on the few Wikipedia lines I read.
Let’s forget about the graphic hardware and API for a while. The flow should look like :

Your application (X Window System sees it as an "X Client")
  ↓ (sends requests defined by the X Window System Core Protocol)
X Server
  ↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
  ↓
Windows or 2D images on your screen

Note that when using the X Window System, your screen and the computer from which you run your application may not be “directly” connected, but could be connected through a network.

Fourth scenario : suppose you want to add fancy 3D graphic renderings to your X Client application from the previous example. It seems to me that the X Window System is not originally able to do this, or at least it would necessitate much convoluted code to perform the equivalent of an OpenGL API function.
Luckily you can use GLX to add support for OpenGL commands to the system. You now have :

Your application
  ↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
  ↓ (convert your request to OpenGL commands)
OpenGL
  ↓ (redirects function calls to implementation defined by)
 ...

Now you can reconnect that last arrow to the one after “OpenGL” in the first scenario : you can get 3D images on your screen !

Finally about what I think understand of the DRI :
It seems to allow Mesa to have access to the GPU, so that would modify the flow of our first scenario into :

...
  ↓
Mesa
  ↓ (forwards OpenGL commands)
DRI
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

And it also seems to short-circuit the flow when using GLX, given the condition that its server and client are on the same computer, and that you have a GPU. In that case the graph of our fourth scenario would simply become :

Your application
  ↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
  ↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
  ↓
3D Images on your screen

That’s it !
Now keep in mind that I’m not an expert in Unix environments, so my best advice is to study the documentation of each of those APIs to know precisely what they can do.
Combining the previous chart into a single one might make things easier to understand. I let this as an exercice to you!

OpenGL is platform agnostic; that means that the OpenGL API is platform independent.

The OpenGL states and buffers are collected by an abstract object, commonly called context.

The hosting platform is responsible to provide some API to create the OpenGL context for the underlying platform. On Windows there are the wgl* routines (Windows for GL), on Unix there are glX* routines (GL for X).

Indeed GLX is nothing but an API that allow application to create OpenGL context, in order to use OpenGL API.

Common WGL/GLX operations are the creation of a window, the creation of an off-screen buffer, make OpenGL context current on a thread, swap draw buffers…

DRI instead is a kernel layer that allow direct communication with the graphic card, by-passing the XServer, indeed speeding up the application using OpenGL routines.

http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html

The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa. Several 3D accelerated drivers have been written to the DRI specification, including drivers for chipsets produced by 3DFX, AMD (formerly ATI), Intel and Matrox.

To put it simply OpenGL is the graphics library type and specification.
Mesa is a base implimentation.
DRI is a hardware interface system.

Mesa basically refers to the whole framework. However, I will presume you are speaking of the Mesa hardware driver.

DRI is basically the kernel interface to handle the hardware. It technically could be used for other things, but it was made for Mesa and is primarily used for Mesa.

GLX is how it all interfaces to X!!

To understand what each part is, you have to know how it fits together.

A program is designed to interface with any openGL library.

GLX is a means to interface OpenGL with or through X11. Depending on if you have a “Direct” interface or an “Indirect” interface depends whether your program will worry about this.

libGL pretty much is the interface for these. It is usually provided by Mesa if you are using a Mesa driver.

In an indirect setup it goes as follows:
Application Framework (i.e. Hard-written application, Engine, or Abstraction API)
|
LibGL
|
Mesa Driver
|
DRI
|
Hardware

In this configuration, GLX is just used on the side to handle the interfacing between your program’s GL use and other programs. Other than GLX specific calls used to do things that require communication the X11 stack and it’s support programs (such as Window Managers) GLX is largely untouched. in this arrangement.

Furthermore, command passthrough and shared memory can be used to further optimize out layers in this system. This all reduces latencies and improves speed to access the hardware. This is what you usually want.

For an indirect it is
Your Application Framework
|
LibGL (User’s side)
|
LibGLX
|
LibGL (X11 Side)
|
Mesa Hardware Driver
|
DRI
|
Hardware

The advantage of this is that you don’t need a direct shared memory buffer with the hardware to use this setup. (Allowing for network clients, as well as more robustness, and a more secure setup.)

This setup can work across multiple VMs sharing a single video card or even accessing across a network because of this. Some forms of shared memory or virtual shared “cloned” memory can be used due to newer extensions, but it is not the direct video memory access found in direct rendering mode.

The disadvantage is the use of pipes or network sockets to interface with X11 can be slow, at the very least introducing latencies on well optimized programs, and at the worst, drastically decreasing frame-rates on poorly optimized ones.

This is the kind of setup is better for networked clients, setups requiring more robust security, and setups where multiple Operating Systems need to share hardware by running through the same GL stack. It’s far from optimal but it gives you some degree of hardware acceleration.