Re: Clip Lists

[Keith W. <ke...@tu...>]

Stephane Marchesin wrote:
> 
> 
> On 11/28/07, *Keith Whitwell* <ke...@tu... 
> <mailto:ke...@tu...>> wrote:
> 
>     Stephane Marchesin wrote:
>      >
>      >
>      > On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann*
>     <san...@da... <mailto:san...@da...>
>      > <mailto: san...@da... <mailto:san...@da...>>> wrote:
>      >
>      >     "Stephane Marchesin" <mar...@ic...
>     <mailto:mar...@ic...>
>      >     <mailto: mar...@ic...
>     <mailto: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.
>      >
>      >
>      > Yes, that is the idea I want to do for nvidia hardware.
>      > Although I'm not sure if we can/want to implement it in term of X
>      > primitives or a new X extension.
>      >
>      >
>      >     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.
>      >
>      >
>      > Since we can put a "wait until vblank on crtc #X" command to a
>     fifo on
>      > nvidia hardware, the vblank issue is non-existent for us. We get
>     precise
>      > vblank without CPU intervention.
> 
>     You still have some issues...
> 
>     The choice is: do you put the wait-until-vblank command in the same fifo
>     as the X server rendering or not?
> 
>     If yes -- you end up with nasty latency for X as its rendering is
>     blocked by swapbuffers.
> 
> 
> Yes, I want to go for that simpler approach first and see if the 
> blocking gets bad (I can't really say until I've tried).

I'm all for experiments such as this.

Although I have a strong belief how it will turn out, nothing is better 
at changing these sorts of beliefs than actual results.

Keith