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? > 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? > 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. > 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. 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. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
