On 7/20/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
Are you talking about accessing the memory out of order? This isn't going to be "simple". There is nothing that is going to absorb CAS latency, and I don't see that getting ahead is necessary. Actually, I was concerned that there might be a problem getting the address 4 to 6 clocks before the data was needed. I don't see that there is anything that can be done about row misses without going to out of order memory access. It is true that if you have several addresses ahead that you could predict a row miss, but the logic would be very messy.
We can't do anything about row misses. But we can do something about pipeline latency when there are no row misses. We can also choose from among requesting agents when one would cause a row miss but another would not.
> > The intended width is two pixels. For simple solid fills, the GPU > won't be able to saturate the memory bandwidth. If you use a few 3D > features, the total demand will exceed memory bandwidth, and the > arbiter can (by virtue of having lots of different types of pending > requests queued up) process accesses in bulk, minimizing the impact of > row misses and keeping all memory controllers maximally busy all of > the time. Thanks for the info. I think that I am wasting your time asking questions. Do we have a block diagram and a technical description of how the OGC chip(s) are going to function? This would be very helpful.
I posted one once on gitk.com, but I can't seem to get into my ftp account there. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
