On Thu, 17 Mar 2005 23:16:13 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote:

> > 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.

I had mentioned earlier that updating the cursor glyph might be
something we would do ONLY in interrupt context.

> 
> > > > 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.

I wasn't clear.  When I say that the GPU "polls the write pointer", I
mean, "the GPU does a DMA read of a word in host memory that contains
the write pointer".  This would be the mode where the write pointer is
not updated in the GPU by a PIO but rather where the GPU reads the
write pointer only at the most convenient and necessary times.

However, when the engine is idle, doing a PIO to the GPU's copy of the
write pointer may indeed be the trigger used to tell the GPU to start
fetching again.

> 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?

Sounds wonderful!
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to