"Stephane Marchesin" <[EMAIL PROTECTED]> writes: > I fail to see how this works with a lockless design. How do you ensure the X > server doesn't change cliprects between the time it has written those in the > shared ring buffer and the time the DRI client picks them up and has the > command fired and actually executed ? Do you lock out the server during that > time ?
The scheme I have been advocating is this: - A new extension is added to the X server, with a PixmapFromBufferObject request. - Clients render into a private back buffer object, for which they used the new extension to generate a pixmap. - When a client wishes to copy something to the frontbuffer (for whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses plain old XCopyArea() with the generated pixmap. The X server is then responsible for any clipping necessary. This scheme puts all clip list management in the X server. No cliprects in shared memory or in the kernel would be required. And no locking is required since the X server is already processing requests in sequence. To synchronize with vblank, a new SYNC counter is introduced that records the number of vblanks since some time in the past. The clients can then issue SyncAwait requests before any copy they want synchronized with vblank. This allows the client to do useful processing while it waits, which I don't believe is the case now. As an additional benefit, the PixmapFromBufferObject request would also be useful as the basis of a better shared-memory feature that allows the memory to be used as target for accelerated rendering, and to be DMA'ed from or mapped into GTT tables. Soren ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
