Packard on the state of Linux graphics

UXA originally was intended to be a bit of a experiment on Intel's part. Just to see how well GEM can be be used. What UXA is is implimenting the EXA API on top of GEM objects.

The idea was once they got the basics going then they would port their changes back to the "EXA" portion Xorg DDX drivers. However they found out that the vast majority of the EXA drivers was not needed and that it was actually much easier for them to write new code for UXA then it was to try to make the old EXA drivers work.

==============

To say that UXA is 'just for video devices with no shared ram' is actually kinda misleading. UXA is a Intel thing and all Intel IGPs use the main memory... however the model of running EXA API on top of GEM (probably through Gallium state-tracker; or porting EXA to use kernel memory management like Intel originally intended) is something that all video card drivers will probably do.

There are a couple reasons why this is misleading...

* The EXA driver in the Xorg DDX uses it's own private memory management scheme and textures objects that are incompatible with those required for OpenGL.

So right now if you want to have composited desktop and want to have full 2D and 3D accelleration you need to:
a. Render the application window in the GPU.
b. Take the pixmap from that GPU, pull it down and do a format change on the CPU
c. push the data back to the GPU to be used as a texture on a OpenGL primative.

Something like that. So that is pretty inefficient and with a discrete GPU with dedicted RAM it may mean moving textures back and forth over the PCI Express bus.

So with the UXA mode of doing things the data is written out to GEM-based memory objects that can be used directly by the OpenGL drivers. Much more efficient. And as you can imagine that with dedicated video RAM avoiding trips back to he CPU is more critical then with the Intel IGP.

* As the driver's capabilities increase it will be able to be used in lots of different manners. You will never really have enough video ram for all tasks, like you can't really have enough main memory for all situations. So video cards are going to take advantage of 'stealing' main memory time to time.

You should be able to eventually use something like LLVM JIT to take advantage of OpenCT on your GPU, be able to use GSLS shaders for programming, be able to use VDPAU for decoding acceleration, and other such things.

When you start to use the video card for more general purpose stuff then you'll never really have enough dedicated video memory to do everyhing you want to do. Even running a basic composited desktop ends up using massive amounts of vram to hold all the application windows textures, if you have a crapload of Windows opens. With that you'd still need to be able to juggle between the needs of the desktop rendering with OpenGL application and games as well as video playback.

For example, imagine if your a scientist that is programming a physics simulation and want to use a python program that not only uses OpenGL for the scientify visualization, but uses C modules built to take advantage of OpenCT to do real time data analysis. Or whatever. Huge amounts of number crunching, multiple different APIs accessing the same card, etc.

Even just for games people are start going to use the GPU in multiple different ways simultaniously. Physics acceleration, AI stuff, raytracing, OpenGL, etc.

So your going to need a way to efficiently and effectively manage swaping video ram out of the video card and into main memory and stuff like that.

So, I beleive, that moden video cards are setup with the idea that you are going to use a combination of both main memory AND dedicated memory. It's, at least, been true for a while that low-end and medium-end discrete graphics cards depend on the driver's ability 'steal' main memory to even function properly on a complex desktop. (like have 64MB of dedicated vRAM, but it's expandable up to 1GB)

Having the memory management done in-kernel and having it unified is critical to making that work very efficiently, especially when your going to have a much more diverse amount of GPU workloads.

-------------------

This is just my understanding of the situation and could be off by several magnitudes of reality. So don't be suprised if I got lots of stuff wrong.