On Tuesday 08 February 2005 21:53, Timothy Miller wrote: > On Tue, 8 Feb 2005 15:31:59 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > > Hi Timothy, > > > > On Sunday 06 February 2005 10:39, Timothy Miller wrote: > > > Well, say it took 4 cycles to compute one sum. Then what you need is > > > dZ, dZ*2, dZ*3, and dZ*4, all of which are either trivial or easy to > > > compute. You use dZ*4 to get to the next loop, and send Z,0; Z,dZ; > > > Z,dZ*2; and Z,dZ*3 down the pipeline. > > > > OK, I just want to tie this one off. It's clear how this will work with > > floating point adders: say the adder requires 4 clocks, and delivers > > one result every clock. For some interpolant T, four steps of dTdx can > > be in the pipeline, and because we compute two pixels on each step, we > > need two adders. The increment will always be 8*dTdx. > > > > We've got something like 17 interpolants, so that's 34 simplified fp > > adders. Interpolating vertically between scan lines will additionally > > use twice as many FP adders as interpolants, because two edges have to > > be interpolated. The edge setup requires a multiply and add per > > interpolant. Should we worry about this number of components, or is it > > no sweat? The vertical rasterization doesn't necessarily have to > > deliver a span per clock but it would be nice if it did, to keep up > > with one and two pixel-wide triangles. > > We only interpolate the left edge vertically, but you do have a good > point that the vertical will double the number of adders. While a > generalized adder takes up a whopping 1% of the design, the simplified > ones won't be nearly so bad. There may be grounds for combining > horizontal and vertical and sharing some of the logic.
Question. I seem to recall that you were going to use fixed-point for the coordinates. The current version of the model, with real float25s, gives some ERROR messages when rendering the antialiased line. As far as I can tell, the problem is that dX1dY and dX2dY just don't have enough precision. If these are converted to fixed-point then there probably won't be a problem, but if they stay float25 then there definitely is. Or maybe we should just use a different algorithm for antialiased lines altogether... Incidentally, would a generic "fixed" class be useful to have for the model? I'm thinking of something that would allow fixed a(11, 5); // 11.5 fixed point fixed b(0, 8); // 0.8 fixed point and so on. It could include cast operators for casting to int and float, and operators would automatically do any required shifting. Actually, we should probably have an unsigned fixed as well then. If this is implemented then it should probably be followed by a walkthrough through the model to decide what is which type and to fix it all up and make it clear what is what. The current implementation is quite sloppy with types. Lourens _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
