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. If no -- you face the question of what to do when cliprects change. The only way to make 'no' work is to effectively block the X server from changing cliprects while such a command is outstanding -- which leads you back to latency issues - probably juddery window moves when 3d is active. I don't think hardware gives you a way out of jail for swapbuffers in the presence of changing cliprects. Keith ------------------------------------------------------------------------- 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
