On 11/27/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
>
> 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.
What if cliprects change between the time you emit them to the fifo and the
time the blit gets executed by the card ? Do you sync to the card in-drm,
effectively killing performance ?
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.
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 ?
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
