Linked by Eugenia Loli on Mon 27th Feb 2006 07:10 UTC, submitted by fsmdave
X11, Window Managers 3D graphics on X11: XGL vs AIGLX. This article delves into the inner workings of XGL and AIGLX. It shows that there are many similarities between these two competing/co-operating "rivals" and plenty of room for growth.
Thread beginning with comment 99634
To read all comments associated with this story, please click here.
Good read
by Ronald Vos on Mon 27th Feb 2006 12:23 UTC
Ronald Vos
Member since:

But is it just me, or is X a mess? (no offense) It all seems so convoluted. I can see why nVidia initially wanted to give up on Linux support. Wouldn't everyone benefit from a rewrite in such a way that OpenGL calls get directly translated to calls to the graphics card, instead of being ping-ponged first?

Reply Score: 2

RE: Good read
by Soulbender on Mon 27th Feb 2006 12:56 in reply to "Good read"
Soulbender Member since:

"But is it just me, or is X a mess?"

It's just you.

Reply Parent Score: 5

RE: Good read
by michi on Mon 27th Feb 2006 13:06 in reply to "Good read"
michi Member since:

You are not the only one that thinks that X needs a rewrite. There is an interesting article by Jon Smirl that gives an overview of the current X architecture and extensions that are used to accelerate X:

Jon Smirl is one of the guys working on Xegl, an XServer that implements the EGL API. It basically is a XServer based on OpenGL (see There is an interesting thread about Xegl on the xorg mailing list (Xegl lives!):
However, I think Jon Smirl doesn't work on Xegl anymore and I don't know if anybody else works on Xegl.

However, NVidia seems to prefer incrementally updating the existing XServer and not rewriting it on top of OpenGL: see

Edited 2006-02-27 13:07

Reply Parent Score: 4

RE: Good read
by Peragrin on Mon 27th Feb 2006 13:30 in reply to "Good read"
Peragrin Member since:

Yes X is a mess. Mostly because of Xfree86's desire to make it one massively convoluted program. is slowly modularizing and breaking it up. So a complete rewrite may be years off it will actually be feasible to do so.

Reply Parent Score: 1

RE[2]: Good read
by Soulbender on Mon 27th Feb 2006 13:47 in reply to "RE: Good read"
Soulbender Member since:

"Yes X is a mess."
You are confusing X the windowing system and protocol with the implementations XFree86 and

Reply Parent Score: 2

RE: Good read
by rayiner on Mon 27th Feb 2006 14:48 in reply to "Good read"
rayiner Member since:

It's convoluted because the underlying problem is a complicated one. First, X supports two mechansisms for rendering OpenGL --- direct and indirect. Indirect rendering is usually used for remote clients --- OpenGL calls get translated into a GLX protocol stream, which gets sent to the X server and rendered. The direct method bypasses the GLX stream, and has the application render directly using a userspace GL library and a kernel module.

Neither mechanism makes "calls" to the graphics card --- since modern GPUs like to be programmed via command packets and not direct MMIO register access. Instead, the direct rendering mechanism allows libGL to create command packets in userspace, and when enough data has been buffered, to call into the kernel DRI (or the NVIDIA equivalent) to verify the correctness of these packets and transfer them to the graphics card.

Reply Parent Score: 5

RE[2]: Good read
by jonsmirl on Mon 27th Feb 2006 15:02 in reply to "RE: Good read"
jonsmirl Member since:

One proposal has been to turn everything into a direct rendering client. Remote apps would get a process forked off to service them, that process would then direct render on behalf of the remote client. Doing this removes the distinction between indirect and direct rendering.

In this model the X server as currently implemented disappears. Everything that draws is direct rendered (including the window/composition manager). Remote clients are handled with external processes (good for security). UI events are routed by the window/composition manager and then sent out to the correct process.

xlib support is handled by splitting some XGL code out into a library which turns the xlib calls into direct rendered OGL.

Edited 2006-02-27 15:03

Reply Parent Score: 5