On Sat, 5 Feb 2005 16:29:59 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Saturday 05 February 2005 09:05, Timothy Miller wrote:
> > On Sat, 5 Feb 2005 02:08:45 -0500, Daniel Phillips
> <[EMAIL PROTECTED]> wrote:
> > > On Friday 04 February 2005 19:29, Lourens Veen wrote:
> > > > On Friday 04 February 2005 23:21, Daniel Phillips wrote:
> > > > > But why can't we solve this with an intermediate queue that
> > > > > holds the same number of entries as stages in the iteration?
> > > >
> > > > Because the producer and the consumer are one and the same piece
> > > > of logic
> > >
> > > I don't believe they are, and even if they were, you'd replicate
> > > it. The problem Timothy is talking about (I think) has more to do
> > > with how you factor the stages and move data between them.
> >
> > No, Lourens is right.
> >
> > But you are correct in that some amount of replication can be done to
> > compensate for that.
> 
> Hi guys,
> 
> Please bear with me, I'm still figuring out how to think about this.
> When I diagramed out my queue scheme, I saw how it just doesn't work.
> So I got rid of the queue and started replicating.  My new idea is to
> have two 16 bit adders, each with two one-clock stages.  One adder
> computes even steps, the other computes odd steps.  The texture pipe
> accepts interpolated results from one or the other, alternating each
> clock.
> 
> Did this solve anything?  A crude diagram is attached.  Each box
> executes in one clock.  The thick lines carry all the interpolants
> between stages.  This bit only handles horizontal stepping.  It would
> be nice but not necessary to be able to step vertically to the next
> span in a single clock as well.
> 
> I'm sure you've already solved this, Timothy.  However, I need to get a
> more accurate handle on what's possible with this hardware, so here we
> go again.

Well, you do and you don't.  The solution to the problem is something
that the driver developer never needs to know about.

I can tell you how it will work, but it's not really something you
NEED to worry about.
_______________________________________________
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