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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
