Quote Originally Posted by ssvb View Post
Hmm, seems like this is really difficult for me to understand. Why would we even need to "update shadowfb in system memory with the results of the 3D rendering in GPU memory"? Doesn't it make a lot more sense to just set up something like periodic DMA transfers from shadowfb system memory to GPU memory (synchronized with screen refresh) and composite it with 3D or Xv buffers together on the GPU side before sending the combined pixel data to HDMI? Or is there some kind of hardware limitation here? Maybe I just need to check the hardware manuals first and not waste your time with silly questions.
It depends on the a lot of factors. Basically, the way shadowfb works is that the master copy of the pixmaps live in system ram. They are stored in system ram and operated on by the CPU in system ram. Then periodically, the front buffer is updated with the results of the all the operations in system ram. It's a one way operation. The CPU copy is always written to the front buffer in vram. When the GPU renders to a buffer in vram (say Xv or OpenGL), the shadow copy no longer has the master copy. Say you want to alpha blend a 3D window with the desktop and some other windows, now you have to get the GPU rendered image into system ram so that the CPU can blend it with the other windows. But wait, can't you have the GPU do the alpha blend? Sure, but then you have to migrate all the CPU buffers that you want to blend into vram so the GPU can access them, so you still have to copy a lot of data around. Wait, can I store everything in gart and get the best of both worlds? Sure, but the problem there is that gart pages have to be pinned so the kernel doesn't swap them out while the GPU is accessing them. Since the kernel can't swap the pages, this limits the amount of memory available to the rest of the system. I think the kernel limits the amount of pinned memory to avoid a driver DOSing the system. With graphics buffers can be huge.

It's easier with a compositor. And you could even support the non-composited case by emulating a composited environment in the driver. In that case you could store the backing pixmaps wherever it makes the most sense (vram or system ram) and then use the GPU to composite the final image. For CPU rendered buffers you'd still need to migrate them to pinned memory for the GPU to access them, but you could keep the shadow front buffer in pinned memory. There are also some tricky corner cases to deal with. It's possible, but it basically comes down to writing a new acceleration architecture which would take time to write and mature. Before going down that road I think it makes sense to see what can be done with an existing acceleration architecture like glamor.