Clip Lists

[Soeren S. <san...@da...>]

"Stephane Marchesin" <mar...@ic...> 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