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