On Nov 27, 2007 11:48 AM, Stephane Marchesin <[EMAIL PROTECTED]> wrote: > On 11/22/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: ... > > It's all delightfully simple, but I'm starting to reconsider whether > > the "lockless" bullet point is realistic. Note, the drawable lock is > > gone, we always render to private back buffers and do swap buffers in > > the kernel, so I'm "only" concerned with the DRI lock here. The idea > > is that since we have the memory manager and the super-ioctl and the X > > server now can push cliprects into the kernel in one atomic operation, > > we would be able to get rid of the DRI lock. My overall question, > > here is, is that feasible? > > How do you plan to ensure that X didn't change the cliprects after you > emitted them to the DRM ?
The idea was that the buffer swap happens in the kernel, triggered by an ioctl. The kernel generates the command stream to execute the swap against the current set of cliprects. The back buffers are always private so the cliprects only come into play when copying from the back buffer to the front buffer. Single buffered visuals are secretly double buffered and implemented the same way. I'm trying to figure now whether it makes more sense to keep cliprects and swapbuffer out of the kernel, which wouldn't change the above much, except the swapbuffer case. I described the idea for swapbuffer in this case in my reply to Thomas: the X server publishes cliprects to the clients through a shared ring buffer, and clients parse the clip rect changes out of this buffer as they need it. When posting a swap buffer request, the buffer head should be included in the super-ioctl so that the kernel can reject stale requests. When that happens, the client must parse the new cliprect info and resubmit an updated swap buffer request. Kristian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
