On Fri, 4 Feb 2005 18:02:16 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Friday 04 February 2005 17:41, Timothy Miller wrote: > > On Fri, 4 Feb 2005 17:21:03 -0500, Daniel Phillips > <[EMAIL PROTECTED]> wrote: > > > But why can't we solve this with an intermediate queue that holds > > > the same number of entries as stages in the iteration? > > > > Ummm... I'm not sure I understand what you're saying, but it sounds > > vaguely like the solution I already have. :) > > The problem is, I don't really know the hardware terminology very well. > I'll try to say it in more words. > > Suppose each horizontal iteration including the divide approximation > requires N stages and yields one pair of results per clock. The goal > is to deliver results to the next stage of the pixel pipeline once per > clock. To get around the N stage latency, instead of delivering > results to the next pixel stage, they are delivered to an N entry > queue, which advances one entry per clock. The horizontal iterator > goes to work on the next pixel pair immediately. Results are thus > delivered to the pixel pipeline once per clock with N clocks latency. > > So latency does not turn into throughput reduction. I think.
I'm still not totally sure if I get what you're trying to say, but it sounds like you're not grokking the interation dependency that's going on in the loop. The iterator cannot immediately go on to the next pixel pair, because it doesn't have the results of the previous iteration. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
