On Tue, Aug 19, 2008 at 12:18 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > On 2008-08-19, Timothy Normand Miller wrote: >> I wouldn't read more than 8 or 16 words at a time anyway. > > Good. > >> A full cache line is fetched for every cache miss. So for random >> access, lots of time is wasted. But sequential is more common. It's >> best to pick a cache size that's a good compromise. > > Does this mean the read requests from PCI will always be aligned when > the cache is on? Can we use the cache for all memory- and engine-to-PCI > operations? That would simplify the code quite a bit.
The read requests to the PCI controller won't be, but when our cache is enabled, you'll get the block address (lower bits will be zero) and a count of words to read (16). The cache is only available to the PCI target. HQ is behind the cache. You can take advantage of the cache in order to reduce the amount of PCI read traffic that HQ has to service. If the memory space is cachable (reads have no side-effects), then enabling the cache is a good idea. If reads have side-effects, then disable it. The cache is never used for engine access. Engine registers can be volatile, so we don't want to return stale data. > >> >> > Another goofy thing: It seems tricky at best to unroll the >> >> > transfer-loop for target write. The reason is that we only know the >> >> > number of queued commands, but what we need is the number of queued >> >> > write-data commands. Any idea? >> >> >> >> That is tricky, and we may have no good answer for that. >> >> >> >> I suggest we do nothing about it right now. We should get a working >> >> revision out, then we can go back later and see if we can do anything >> >> clever with the CPU design. >> > >> > Okay, we don't unroll, but we can still avoid sending an address for >> > each write request. >> >> You can, although the check to decide whether or not to send an >> address would probably take longer than just sending an address. It >> depends on what you're doing. >> >> For instance, if you get an address and some writes, then you don't >> get anything, so you go on about some VGA business, then you get >> another write without an address, you'll have to reissue the correct >> address (where PCI left off), because you may have changed it to >> access some memory for what VGA needs to do. > > My idea was to enter an inner loop once we have a write, and exit to the > top level on the first non-write. If writes occur then nothing, you'll never see a non-write. The only solution is to bring some PCI state info into where HQ can get at it. For instance, we could add a null command to the fifo. Whenever the target terminates a transaction, we send this null command down the command pipe. The bridge should be designed to ignore it, but HQ can use it as a hint that writes are done. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
