On Tue, 8 Feb 2005 23:48:08 +0100, Lourens Veen <[EMAIL PROTECTED]> wrote: > 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...
Are you sure it's a lack of precision? I've gotten lots of those messages when I just didn't program things right. How are you generating rasterizer parameters? Man, I haven't even checked out the new tree yet. <sheepish grin> I was going to earlier, but I discovered that I'd neglected to emerge subversion. That's probably done now, but I've been up to my ears in other things today. > > Incidentally, would a generic "fixed" class be useful to have for the model? > I'm thinking of something that would allow To some extent. The model should evolve to more closely resemble the hardware. Some discussion needs to happen with regard to what precision is necessary for each fragment attribute AFTER perspective divide. At that point, it's predictable, and we don't lose precision. > 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. Excellent! > 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. Yeah, I thought about them somewhat, but I was trying to make it conceptually correct first. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
