On Tue, 22 Mar 2005 12:05:52 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Tuesday 22 March 2005 10:46, Timothy Miller wrote: > > On Tue, 22 Mar 2005 10:31:15 -0500, Daniel Phillips 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. > > An ioctl gives you synchronous communication from the kernel, initiated > by a userspace task. A socket (or pipe pair) gives you two-way > asynchronous communication, which is fundamentally more flexible and > quite useful for the immediate problem. It is true, you can in theory > build any possible interface and control it with an ioctl. However, if > the interface you build is essentially a socket, then why not use the > real thing?
Sockets are designed for user-user IPC. They are NOT designed for user-kernel transactions. When doing user-kernel transactions, we use a more appropriate tool. > > > 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. > > So this ioctl returns immediately, I presume. How does the kernel > notify user space that the indirect DMA has completed? Another ioctl? And no, I'm not talking about polling. > > 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; > > Continuance? > > > 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. > > By "continuance" I think you mean a normal kernel semaphore, which is > sometimes used this way. I think that's what they call it. Linux does have "regular semaphors", but they're mosly being replaced by more specialized types of semaphors, optimized for their uses. One kind of semaphor, called a lock, is optimized to be more efficient in the "don't sleep" case, while the continuances are optimized for the sleep case. > > > If you hit the timeout, there's a problem, so you go and discover the > > cause and recover. Und so weiter. > > We can forget about the timeout for now, it is only an error path. The timeout still has to happen, otherwise, you could lock up forever. > If you rely only on the blocking ioctl mechanism you described then you > can't implement the double buffer interface style I showed above. The > nonblocking ioctl leaves open the question of how to notify the > rendering task that the indirect DMA has completed. You need another > mechanism for that. This is where the socket comes in. You CAN implement the double-buffer mechanism. Like this: - Submit command set A - Submit command set B - Sleep until A is completed - Submit A - Sleep until B - Submit B - etc. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
