A New Acceleration Architecture For X

XAA, or the XFree86 Acceleration Architecture, is over twelve years old and finally in 2005 it was greeted by a replacement, EXA. XAA is nearing an end-of-life and Intel is prepared to remove XAA acceleration within their next Intel graphics driver release later this year. EXA was designed to offer speed improvements over XAA by accelerating more options and enhancing X's RENDER extension. Depending upon the driver, it wasn't until recently though that EXA really did have some modest speed advantages. A new acceleration architecture has now joined the mix. Intel's Keith Packard has announced UXA, which is short for the UMA Acceleration Architecture.

It seems as of late whenever we bring up Intel and X.Org together, something always relates back to GEM (even X Server 1.5 losing DRI2 support). This new acceleration architecture is also coming because of GEM. For those that have yet to hear of GEM, it's an acronym for the Graphics Execution Manager that is Intel's kernel memory manager for graphics and came because of a falling out over the TTM memory manager.

Keith Packard and his Intel team have been working to bring GEM's memory management capabilities to the 2D space. This is to allow the 2D xf86-video-intel driver to work with Pixmaps as GEM objects, which as Keith describes "to enable the GLX_EXT_texture_from_pixmap extension in an efficient fashion." While Keith likes the API for 2D EXA acceleration, he doesn't like the EXA code. Rather than working on just improving EXA, he once again decides to start something new.

Keith started out with the EXA code-base and then stripped out a lot of the code and then added in the GEM bits. The result is what Keith describes as the UMA Acceleration Architecture (UXA) at about 5,000 lines of code. This 2D acceleration architecture isn't yet found in the X Server, but once they decide how they want the infrastructure to be, they'll move it from the Intel driver and into the server.

The Pixmaps-in-GEM code is working but there are a few performance limitations and other issues being worked out. All of the details in full can be found on Keith Packard's blog. Eventually they may move some of this work back into EXA, but it looks like the GEM-dependent UXA may be here to stay.