Pushing image transport logic down the stack

[Allen Akin]

On Sun, Sep 03, 2006 at 11:50:07PM +0100, Alan Cox wrote:
| Ar Sul, 2006-09-03 am 17:16 -0400, ysgrifennodd Owen Taylor:
| >  - A copy from and format conversion from your own data to the 
| >    shm buffer
| >  - A copy from the shm buffer onto the destination drawable
| 
| That's an X implementation limitation. Given kernel support it is
| perfectly possible to pin those pages and a kernel drive let a video
| card DMA those shm buffer pages.

Since early 2004 OpenGL has had a mechanism called "pixel buffer
objects" which (among other things) does what Alan suggests.  Since it
can be used to source data for the full OpenGL pixel pipeline, it can
also accelerate quite a few format conversions in addition to
eliminating data copies.

It would be great if X could use that same mechanism rather than
creating a new one.  If not, it would be nice to make sure that the new
one plays well with the existing one and doesn't require driver
developers to implement a lot of very-nearly-the-same-but-slightly-different
functionality.

Buffer objects, which can store many kinds of data in addition to
pixels, are pretty important to the OpenGL API for the foreseeable
future.  For the current specifications, see:

	http://opengl.org/documentation/specs/version2.1/glspec21.pdf
		(section 2.9)

or the extension specs from which the core functionality is derived,
which have some useful background information:

	http://opengl.org/registry/specs/ARB/vertex_buffer_object.txt
	http://opengl.org/registry/specs/ARB/pixel_buffer_object.txt

Allen