Pushing image transport logic down the stack
sandmann at daimi.au.dk
Mon Sep 4 21:11:38 PDT 2006
Keith Packard <keithp at keithp.com> writes:
> I'm interested in learning how we could create a shared object that
> referred to existing address space. We already do that from user space
> to kernel; why not between two processes?
One thing that should be kept in mind is the interaction with the
graphics memory manager. In a world where the memory manager is the
only entity knowing the exact location of graphics buffers, this is
also the only entity that can actually initiate DMA.
For some time my view has been that the memory manager should be part
of a generic kernel graphics driver with these features:
- Has API for applications to allocate and deallocate buffers. When a
buffer is allocated, a globally unique handle is returned to
userspace applications who are allowed to share them with
eachother. A buffer can be initialized with data from the
- Applications can submit command buffers. If the commands need to
refer to buffers, they pass handles instead along with information
about where in the command stream such handles are located. The
driver is then responsible for fixing them up.
- The driver will validate the command buffers to make sure they don't
DMA to random places in memory.
- Individual command buffers are guaranteed to be executed
Given this API, an image transfer between application and X server
becomes a matter of simply sending a buffer handle. If the application
is willing to commit to never changing the data, it would never even
have to be DMA'ed; it could just be mapped into AGP space as needed.
More information about the xorg