On Thu, 24 Feb 2005 15:16:54 +0100, Lourens Veen <[EMAIL PROTECTED]> wrote: > On Thursday 24 February 2005 03:43, Daniel Phillips wrote: > > On Wednesday 23 February 2005 20:40, Timothy Miller wrote: > > > > > ...There are two sets of texture registers, but there is only > > > one texture unit that can read only two pixels per clock from RAM. > > > > I've been wondering about that. Why do we bother interpolating two > > textures times two pixels per clock if we can only texture at half that > > rate? Wouldn't it make sense to interpolate fewer parameters per clock > > and alternate the pipeline when somebody turns modulation on? > > Can we do something with the mipmapping constraints? If we have two pixels > side-by-side, what know about the texels that will be sampled? Is there any > guaranteed overlap? That would save some RAM bandwidth. > > Now, let's 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. 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?
The memory controller will be designed with a set of "ports" which are connections to agents that need access to memory. I then prioritizes requests and accesses memory as necessary. In fact, there'll be four memory controllers working somewhat independently. Anyhow, each port will have its own very small cache. This way, accessing the same pixel twice does not require a re-read of memory. (Although the two texture units will share a port, I think I want to give each one its own cache.) Caching with low overhead can result in non-coherency. Therefore, certain things like bitblts will need to be able to specify that the read caches are to be flushed before reading starts (and other similar things). _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
