Pushing image transport logic down the stack

[Alan Cox]

Ar Llu, 2006-09-04 am 08:47 -0400, ysgrifennodd Owen Taylor:
> 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

(I assume you mean pass by reference here)
> 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.

SYS5 shm isn't the most efficient way but it isn't that inefficient
either. The create/destroy cycle is also inefficient because you don't
neccessarily need to do it in all cases.

Assuming the X server didn't need to touch the pages (ie you could work
out what can be done in advance) then the DRI layer does close to what
is needed at the moment.

You allocate some pages of your own address space (which may be shared
with other clients assuming MAP_SHARED is used and you've got things
like themes file backed), you pass them to the DRI layer which
references them, locks them if need be and issues 3D command sequences.
It then frees its use of them and you get them back.

For the existing shm type model going to posix shared memory would
probably be more efficient and you can do more useful things with it but
it isn't much different. You can mmap it then and have real handles and
paths (eg you can pass the file handle to posix shm down an AF_UNIX
socket), and you can delete it and it will go away on last close ..

Neither solves the network case where you really want the object
residing in the remote server.

Alan