Hi Timothy, On Friday 25 February 2005 07:55, Timothy Miller wrote: > On Thu, 24 Feb 2005 18:22:28 -0500, Daniel Phillips wrote: > > 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. > > I was thinking four entries, more precisely two pixel pairs. :)
Ah, that makes sense. There is a total of 8 pixel pairs, or 16 pixels. This should work ok for bilinear blending, but for trilinear blending there are two separate textures, which will break the cache completely. What's worse is, the two textures will be on different DRAM rows, so this is where the cache is really needed. Doubling the cache to four pixel pairs per port should fix this. Again, sharing the cache between all four ports is something to think about, it might reduce the total footprint at the expense of more design complexity. Something for a later rev? OK, with a tiny cache a round robin replacement policy is way too crude, so here is a better suggestion: for each cache miss, search for a cache entry that is in the same texture but not adjacent either vertically or horizontally to the new pixel pair and replace that one. For the common case where the filter footprint is moving in any direction one texel at a time, this replacement policy is optimal. The "in the same texture" test is aimed at the trilinear filtering case, which is the one that needs optimizing. 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)
