On Fri, 25 Feb 2005 14:03:12 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > 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.
Yeah, you're right. The reason for having two pairs is to deal with fetch requests on odd boundaries. But we need another two for the other row. > > 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? The reason for more smaller caches is so that one stream does not hog the cache, killing needed efficiency in another. > > 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. Anything more sophisticated than simple tables with LRU replacement is going to require too much logic. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
