Request for sponsered development...

[Adam Jackson]

On 3/11/11 8:01 AM, Christian Weiß wrote:

> Since AIGLX is a Fedora project, I hope that anyone here is able to
> provide me with further technical information about the protocol and
> the architecture - haven't found anything so far. As mentioned,
> whatever comes out of this I'll gladly contribute to the project.

AIGLX is mostly just a standard feature at this point.  And sort of an 
uninteresting one.

Let's break the acronym down.  GLX is GLX, the binding between OpenGL 
rendering and the X window system; it's how you get GL to draw to 
windows or pixmaps.  I is "indirect", because GLX has two modes.  In 
direct rendering, the X client sends most rendering commands to the 
hardware directly, and only interacts with the X server for coordination 
purposes (where in memory does a given pixmap live, when to swap, etc.) 
  But in indirect GLX, it behaves more like everything else in X, where 
both rendering and management commands are passed from client to server, 
and the server executes them.  Direct is an optimization for local 
clients, though they can use indirect too if they choose; remote clients 
can only use indirect.

"A" means accelerated, and the reason for that is somewhat historical. 
Back in the day (1999 through 2006 or so), the X server's rendering code 
for indirect GLX was a clever build of the software rendering code in 
Mesa.  This worked well enough for what it was, but was always sort of a 
hack.  The "A" bit came about when we taught the X server how to load 
DRI drivers the way libGL does on the client side.  The advantage to 
doing that is that indirect contexts become faster.

But at the time, the _real_ advantage to that was that it made this 
other extension actually feasible.  GLX_EXT_texture_from_pixmap is a GLX 
extension that does what it says on the box; it allows you to turn 
existing pixmap contents into a texture.  Back then, we didn't have any 
real memory management in the DRI drivers, so there was no easy way for 
the X server and GL clients to share memory (ie, pixmaps).  So in direct 
GLX there was basically no way to implement this.  In indirect GLX, 
however, you have the GL renderer and the X server in the same address 
space; turning pixmaps into textures is a small matter of passing around 
a pointer (and compensating for X and GL having a different Y axis 
convention).  So that was the whole motivation for AIGLX: you needed 
texture from pixmap to make compositors work, and the easiest way to 
make that go fast was to load the DRI driver in the X server.

(The competing solution for this was Xglx, which achieved the same goal 
of "accelerated 3d renderer in the same address space as your pixmaps" 
by being a proxy X server, itself a direct-rendering client of the 
backing X server.  Both approaches are valid enough, and the final 
decision to go with AIGLX was IMO driven mostly by parsimony: fewer 
moving parts, better symmetry between client and server.)

But now?  Sort of pointless.  GEM and TTM and whatnot serve the purpose 
of coordinating video memory between multiple apps, one of which just 
happens to be the X server, so sharing buffers between GL client and X 
server is trivial: you ask the kernel.  That means you can implement 
EXT_texture_from_pixmap in direct contexts efficiently, which means 
indirect GL loses its feature advantage.

For your purposes, AIGLX is merely a promise that GLX will be fast, 
regardless of whether the X client and X server are on the same machine. 
  The key is to remember that GLX is a rendering protocol, not a 
remoting protocol.  Your viewer, wherever it is, will probably use GLX 
to do the final rendering, but the the thing that moves your compressed 
textures over the wire (along with the rest of the session) need not and 
probably should not be X11.

- ajax