On Thursday 17 March 2005 21:46, Timothy Miller wrote: > On Thu, 17 Mar 2005 21:40:57 -0500, Daniel Phillips wrote: > > > We also need to consider, in all cases, what happens when you try > > > to do a PIO while DMA is going on: You wait for, like, 16+ bus > > > cycles just to get in one transaction. > > > > My suggestion is to not implement PIO at all, except for the basic > > card control commands. I do not think PIO as an alternate means of > > issuing commands adds any useful functionality. > > > > I also suggest that PIO commands, direct DMA commands and indirect > > DMA commands should not overlap. At this point, I haven't seen any > > examples at all of where overlap makes sense. > > Updating cursor glyph in interrupt context while DMA is going on. > Note that the latency for that could be evil.
It is also a dodgy/evil thing to do. How do you know you're not interrupting another cursor glyph update? I would strongly suggest that if an interrupt routine wants to update the cursor, it should use interprocess communication to have a foreground task do it, or use a work queue. We are talking about microscopic latency here. > > > The simplest approach is to use PIO to push DMA commands into a > > > queue. But that has the latency issue when a DMA transaction is > > > already going on. The fastest approach is the one where the host > > > does absolutely no PIO at all and it's the GPU's job to poll the > > > write pointer and update the read pointer at convenient times. > > > > I doubt the GPU needs to poll. Each of those ring buffer commands > > is going to take quite some time to execute, and they will almost > > always be submitted in batches. When they aren't, I don't think we > > care. > > The GPU will "poll" the write pointer under two conditions: > > (1) The fifo for the ring buffer is running low and should be loaded > with new commands, if available. > (2) The engine is completely idle. (1) sounds right. I don't see how (2) improves things, because (1) should have already taken care of it. But I still don't see why polling even comes into it. If somebody writes the PIO and the buffer isn't below the threshold, then nothing happens, except that a buffer low interrupt will be enabled (but not dispatched). > It's hard to completely eliminate (2). I suppose if we also > interrupt on engine-idle, we can set a state bit that indicates that > we have to do one PIO to kick-start the DMA for the ring buffer. > Could that ever get confused? My spider sense is tingling. I would think that writing the ring buffer tail register is all that is needed, and if we have lost track of whether we have already done that or not, then that's a driver bug. We've covered a lot of ground today. A lot of issues were clarified and a lot of important details emerged. How about I try to get it down on paper over the next day or two and make a formal proposal out of it, so we can beat it to death and then maybe put in the wiki? 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)
