Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-vax!keith
From: keith@mit-vax.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.arch
Subject: Re: PMAX/DS3100 frame buffers
Message-ID: <5845@mit-vax.LCS.MIT.EDU>
Date: 22 Mar 89 04:10:13 GMT
References: <93849@sun.Eng.Sun.COM>
Reply-To: keith@mit-vax.UUCP (Keith Packard)
Organization: MIT Laboratory for Computer Science, Cambridge
Lines: 29

In article <93849@sun.Eng.Sun.COM> david@sun.com (Do you, Peanut Butter, take this Jelly...) writes:
>Does anyone know for sure if the PMAX frame buffers are cached?

The PMAX frame buffers are not cached.  Naturally, the hardware would 
allow this, but it is disabled.

>Any comments on the pros and cons of caching frame buffers?

I've been convinced that caching the frame buffer is a bad idea.  The reason
is obvious in the 8-bit color frame buffer mode.  In 8 bit mode, the machine
is almost never reading data back from the frame buffer for drawing.  When
blting, you almost always read a tremendous amount of sequential data, so
the amount of useful data in the cache is probably zero.  Worse yet, you're
ending up with a data cache full of data you'll never need again (i.e. the
bits just blted).

A monochrome system is less clear; I've been told that benchmarks on the
PMAX tend to favor an uncached system.

Now, if the cache was a bit fancier and did burst mode for filling
a long run of data on a read miss, then blt might be faster with
the cache turned on.

I'd rather see special blt hardware though.  I can imagine all sorts
of fun uses (like system/user data copy) for a fast piece of general
memory copy hardware.

keith packard
keith@expo.lcs.mit.edu