Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!dg!mpogue
From: mpogue@dg.dg.com (Mike Pogue)
Newsgroups: comp.arch
Subject: Re: hmmm
Message-ID: <272@dg.dg.com>
Date: 19 Feb 90 23:57:22 GMT
References: <7398@pdn.paradyne.com> <1990Feb18.084034.7015@utzoo.uucp> <22609@mimsy.umd.edu>
Reply-To: uunet!dg!mpogue (Mike Pogue)
Organization: Data General, Westboro, MA.
Lines: 41

In article <22609@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>In article <1990Feb18.084034.7015@utzoo.uucp> henry@utzoo.uucp
>(Henry Spencer) writes:

>Another interesting side issue is what happens as screens get denser
>(e.g., 2048x2048 24 bit true color displays showing text): the number of
>bits or bytes moved to draw a character goes up to the point where the
>move starts to dominate again.  When we reach page-quality screens
>(4k x 4k or higher) we will definitely need something fancy (a complete
>4096x4096x24 display is 48 MB, which is a lot to move in a short time).
>Fortunately, we have some time before these displays will become popular. :-)

  Actually, this is exactly what we have found.  The memory-CPU bandwidth is simply
not big enough in a low end machine, to support BITBLTs on Color screens.

  I think DEC found this out, when they looked at where all the time was being
spent on their 2100/3100 workstations.  Their next workstation (or so it has
been reported) supports BITBLT in hardware.

  In fact, the January 29, 1990 issue of EE Times quotes ONLY BITBLT performance
and rectangle fill.  Where are the vectors/second numbers?  Maybe they aren't
any faster than on the raw 2100/3100 hardware....We'll have to wait and see.

  For peppy response, we have found it typically takes about 20M pixels/second
BITBLT speed.  Less than that, and things appear sluggish.  On an 8 bit/pixel
color system, this works out to moving (rotate/merge included) about 20M bytes/second.

  A 24b/p design is even worse, requiring a minimum of 3 * 20M = 60M bytes/second.
Memory in this case is often organized to support 24/32 bits/pixel, which requires
a read and a write per pixel (4 bytes at a time).  This is then 20M reads/second
and 20M writes/second, something most RISCs (remember video memory is not normally 
cached!) really don't want to sit around doing.

  On the AViiON 300, 400, SparcStation GXP, the BITBLT engine is in hardware.  Doing it
by an instruction in the RISC CPU will NOT be good enough, IMHO, until the clock rates
and the CPU-Video Memory bandwidth go way up.

Mike Pogue
Data General

Speaking for myself....