On Tuesday 08 February 2005 15:06, Lourens Veen wrote: > Yep. I'd already found out empirically that when doing linear > interpolation between 16-bit values I would get 15 bits precision. > OTOH, I guess it should be possible to make it 16...I'll have a look. > Or maybe using 18-bit words in the LUT could improve that to 16 bits. > The problem is that you need to read two values per pixel, and the > RAM is dual-ported, so we can't do two pixels at the same time. > Unless we use two RAM blocks, one table for each pixel. How scarce > are these things?
There are 40, however I think I saw Timothy say that the 40 RAM blocks and the 40 dedicated multipliers come out of the same budget, which would make things tight. Fortunately, only two reciprocal units are needed, so using 10% of the RAM/Multiplier budget (if that's how it works) doesn't seem too horrible. It's the interpolants that are really going to eat multipliers: Horizontal rasterization: - two multiplies per interpolant for perspective correction Vertical rasterization: - one multiply per interpolant to correct for pixel alignment With 17 interpolants, most of which need perspective correction (in my opinion; some may think this justifiable only for textures) we've already exceeded our multiplier budget and haven't even begun to think about filtering, blending, mipmapping, fog and probably other things. So pretty soon it's time to make some hard choices about what is expendable, where to compromise on quality and throughput, and how throughput is going to degrade gracefully as features are turned on. All of which I'm sure Timothy has been thinking about, but now it's about time to take inventory and see just how bad things are. It's also possible to create more multipliers in random logic, as Timothy mentioned several times, but this is only going to work out in places where precision is really limited. I hope I'm wrong about multipliers and block RAM coming out of the same budget. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
