Pushing image transport logic down the stack

[Owen Taylor]

On Mon, 2006-09-04 at 11:50 +0100, Alan Cox wrote:

> > I don't think the SHM extension really works out very well for
> > most applications once you take a broader view of success.
> 
> Any "direct" API I can imagine is going to look something like
> 
> Allocate Object
> Put Data In It
> Pass To X Server
> 
> Once you want to do reuse then you either have the server telling the
> client when it has finished and/or refcounting.
> 
> I'm not sure how much more we could do to improve on the state of
> things, and Sys5 shared memory (or perhaps posix shared memory would be
> nicer these days) has the same life model that is needed as well as
> being pageable.

Well, there are a couple of design issues with the SHM extension to X
that are independent of the kernel mechanism:

 - The completion mechanism is inconvenient ... you have to wait for
   an X event, but peeking ahead through the X queue is pretty 
   inefficient. (Async mechanisms can help)

   What would work really well in a lot of cases would be to have a 
   counter and a semaphore in the shared memory block, so you could
   simply wait for some particular earlier drawing operation to 
   complete.

 - Shared memory images and pixmaps are 2D, but that doesn't work very
   well for subdivision of larger buffers. It would be better to
   simplify have linear buffers.

But beyond that, the real issue with using SHM is the cost of the setup;
to set up a SHM segment, you typically:

 1. Create the segment
 2. Attach to the segment
 2. Ask the X server to attach to it and wait synchronously for
    acknowledgment.
 3. Destroy the segment (so that when you and the X server detach
    it will be released)

I don't have numbers about how long that all takes, unfortunately, but
it's certainly significant. 

So, if you are going to create SHM images, use them once, and then
stop using them, you need a pretty big image - likely megabytes -
for using SHM to be useful.

But if you instead are going to keep SHM images around, then, well,
you need decently sized buffers for SHM to be effective; constantly
reusing a single 16k SHM buffer isn't going to do much good. But do you
really want every app on the desktop to keep around several 100k of 
buffers permanently? My desktop currently has > 12M of such those
buffers.

So, could there be a better kernel API?

Well, the pipedream would be that you'd be able to allocate a bunch 
of pages, put data into them, pass them over the X socket to the
server, the server picks them up, uses them, and when the graphics
engine is done, releases them back to the kernel.

Are the page table manipulation costs of such an API low enough to
make it feasible? I have no idea.

Alternatively, improving the efficiency of the standard 
XPutImage() / write() path makes the need for shared memory less; 
as mentioned in my earlier mail, vmsplice() could possibly be
useful to that end.

					- Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060904/4eab68e2/attachment.pgp>