keith@xenon.lcs.mit.edu (Keith Packard) (04/23/91)
Henry Spencer writes > Anybody who caches a frame buffer is crazy. Especially if the cache isn't > write-through, in which case your frame-buffer updates show up on the screen > some arbitrary time later! While this may in general be true; and I've got numbers to prove it for several machines, there are a few memory architectures which are broken to the point where it becomes advantageous to cache the frame buffer. In particular, the MIPS Magnum memory system will not generate page-mode writes except through a cache line flush; therefore writes to uncached locations always take a full memory cycle, while sequential writes through the cache hits page mode making large area refreshes quite a bit faster. It becomes quite apparent to the user that the frame buffer is cached when the font data colides with the screen - text performance is effectively halved. To alievate the cache-busting nature of the frame buffer, they map each scan line into 4K bytes, so only 1/4 of the cache is destroyed by frame buffer access. This makes things pretty awful for the TLB however. Which would tend to make drawing lines very slow, except that they also provide an alternative mapping scheme which maps square sections of the screen into sequential memory locations. Hack upon Hack upon Hack.