On Thursday 24 February 2005 09:16, Lourens Veen wrote: > say pixel 0 has four texels it samples from from the > largest mipmap. The distance to pixel 1 on that mipmap is larger than > 1, but smaller than 2 (otherwise we'd be at the next mip level). That > means it's possible to have no overlap there, if the fractions are > 0.5, 0.5 and the scaling is so that the next pixel is 2 texels > further along an axis. It's a very small chance, but it is possible. > On the smaller mipmap, the distance is between 0.5 and 1, and we're > guaranteed to have some overlap.
Actually, the filter footprint should overlap at least a few texels nearly all the time at every mipmap level, since the purpose of mipmapping is to try to keep screen pixels and texture pixels as close to the same size as possible. > The question is how to figure out > which texels. Maybe it would be possible to create a small cache > (just a few registers really) on-chip? Oh boy, now it gets fun :-) Here are a few random thoughts on cache design... Each cache element has to be tagged, probably with a 23 bit address. Each cache element has to be able to compare against the requested address. A cache line is 32 bits, probably. I think we need at least 16 entries to get any measurable improvement from it. Timothy has suggested that each memory controller will have its own cache, and I can see how that simplifies things, but on the other hand it will require more cache entries in total to get the same benefit versus a shared cache. Then there is replacement policy. Round robin is probably the right one. 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)
