On Tue, 22 Mar 2005 10:31:15 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Tuesday 22 March 2005 03:57, Nicolai Haehnle wrote: > > On Tuesday 22 March 2005 04:32, Daniel Phillips wrote: > > > Now consider: > > > > > > * DRM allocates two DMA buffers, A and B > > > * application draws via DRM into A until full > > > * DRM submits A > > > * draw into B via DRM until full > > > * DRM submits B and waits for socket data > > > * DRM wakes up and receives completion for A > > > * draw into A via DRM until full > > > * DRM submits A and waits for socket data > > > * DRM wakes up and receives completion for B > > > * repeat > > > > > > With this interface style, the drawing pipeline is never idle. > > > This goodness is realized even though the drawing task is > > > inherently linear - we haven't even done anything fancy with poll > > > yet. > > > > And we can do all this with ioctls. > > Would you illustrate how, please.
You can make an ioctl do whatever you want. So, let's say you want two of them. One's async that takes an indirect DMA block and either submits it and returns success or returns failure, and another one does the same but blocks on failure. Well, the first one's obvious. Do your copy-in of the pointer, generate the direct packet, etc. The second one, on finding that it can't submit the packet needs to block. Blocking's easy. Linux has these things, I believe they're called continuances. They're like semaphors that you use to lock yourself; the usual scheduler mechanisms in the kernel take over. But just before that, you set up the ISR and a time-out routine. Whichever comes first unlocks the continuance, and you unblock. If you hit the timeout, there's a problem, so you go and discover the cause and recover. Und so weiter. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
