Pushing image transport logic down the stack

[Soeren Sandmann]

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
  application'smemory.

- 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
  atomically. 

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.


Soren