One thing to note: There is enough benefit to doing some of this automatically that I intend to put in necessary hardware locking mechanisms to take care of some of this. If you have an operation that requires a "flush", all you do is set a bit in the command. When the flag hits the texture unit, it clears the caches and blocks. When it finally reaches the write stage and makes it out to memory, it unblocks. It's a relatively simple mechanism.
Another thing: In TROZ, we wanted to maintain coherency between engine access to memory and host access to memory. While there are explicit ways to flush the caches (and we use them sometimes), the caches also have expiration counters. It's unusual to have host and engine access going on at the same time (some chips hang up when you try to do this), but as long as host and engine were accessing different parts of memory, it was fine, and if you switch back and forth between engine and host access, the timers usually expire in time, and coherency is maintained. On Fri, 25 Feb 2005 13:12:16 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Friday 25 February 2005 07:53, Timothy Miller wrote: > > the basic idea is, "What do you do when you write to an > > address that's represented in a read cache?" Simple answer: Whenever > > you're going to read something you may have written to, flush the read > > caches. > > Flushing the read caches in itself isn't enough because we also have to > worry about write-read ordering. If ReadPixels operates independently of > the rendering pipeline, we need to synchronize it somehow. The easiest way > is to flush the pipeline, either explicitly with a graphics command as > Nicolai suggested or implicitly with dedicated logic. > > On the other hand, it would be easy to make ReadPixels use the graphics > pipeline, which gets rid of the race in a rather expensive way. But it > would still be fast enough to saturate the PCI bus. > > 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)
