Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!sdd.hp.com!mips!dd
From: dd@mips.com (Oh, duct tape has its place...)
Newsgroups: comp.arch
Subject: Re: Magnum Workstation and Cached Framebuffers
Message-ID: <2700@spim.mips.COM>
Date: 25 Apr 91 21:40:26 GMT
References: <2559@spim.mips.COM>
Sender: news@mips.COM
Lines: 20
Nntp-Posting-Host: slack.mips.com
Originator: dd@slack.mips.com

In article <2559@spim.mips.COM> rowen@mips.com (Chris Rowen) writes:
>In normal use, successive 2K (1280 visible, 768 non-visible) scan lines
>are mapped at 32K intervals.  This means that all scan lines map to
>the same 2K region of the cache -- only 1/16 of the cache is destroyed by
>frame buffer.  If you assume that the non-visible portion of the scan line
>is rarely touched, only 3.9% of the cache is clobbered.

As I mentioned in a previous posting, RISC/os remaps the frame buffer so
that to a user process the scan lines appear to be 4K apart.  However, as
Chris politely reminded me, the Magnum has physical caches, so that this
remapping does not affect the portion of the cache that is "clobbered".
Chris's 3.9% number is correct, and I apologize for claiming otherwise.

If cache conflicts severely degrade performance for a particular operation
such as text drawing, it would probably be worthwhile to make an effort to
allocate storage for the data used by that operation so it doesn't alias
with the frame buffer.  I guess this would be considered a hack.

--
David DiGiacomo, MIPS Computer Systems, Sunnyvale, CA  dd@mips.com