On 11/28/07, Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
> Stephane Marchesin wrote:
> >
> >
> > On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > "Stephane Marchesin" <[EMAIL PROTECTED]
> > <mailto:[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.
> >
> >
> > 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).
Stephane
-------------------------------------------------------------------------
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
