🚀 go-pugleaf

In article <1991Apr23.152155.2298@zoo.toronto.edu> henry@zoo.toronto.edu (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!

  The second part of this is true, but in a system which writes data to
the bus aggressively, the arbitrary time is in ms, not seconds or
minutes.

  Write-back cache seems to fall into the group which trys to unload the
bus by only writing to memory when the cache is getting full, and the
aggressive cache which writes whenever the bus is not busy. I played
with caching a frame buffer, and it had a positive effect on
performance, since calculation and writing of points was overlapped.

  Obviously a bank selected frame buffer can't (easily) be cached, but
other than that I don't see any reason why cache won't work nicely. I
don't think a write-through cache would make sense because *most*
programs don't read back the buffer.

  I agree with the conclusion, that caching a frame buffer is not cost
effective in most applications, but I'm not quite as firmly set against
it as Henry.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
        "Most of the VAX instructions are in microcode,
         but halt and no-op are in hardware for efficiency"