Newsgroups: sci.electronics
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Frame Buffers
Message-ID: <1990Jun27.152249.3030@utzoo.uucp>
Organization: U of Toronto Zoology
References: <2229@mindlink.UUCP> <1990Jun26.154640.26941@utzoo.uucp> <1990Jun26.200549.792@amd.com>
Date: Wed, 27 Jun 90 15:22:49 GMT

In article <1990Jun26.200549.792@amd.com> phil@pepsi.amd.com (Phil Ngai) writes:
>|Nobody in his
>|right mind uses anything but VRAMs for frame buffers unless there is some
>|compelling reason why they won't work for the particular application.
>
>I wouldn't be quite so strong about that. VRAMs are a lot more expensive
>than regular DRAMs, and since you can run 50 ns page mode cycles on
>ordinary DRAMs, you can easily get 20 Mhz * 32 = 640 million bits/sec
>or 80 million 8-bit pixels/sec out of 1 megabyte of memory (8 x 256K x 4).
>That's 1.3 million pixels/frame at 60 Hz.

At the cost of using the entire DRAM bandwidth, leaving none for updates!
I said "in his right mind". :-)  Given that modern CPUs can routinely drive
a memory system until the bolts fall out, and people complain that the
CPU nevertheless can't update the display quickly enough, a well-designed
frame buffer needs plenty of update bandwidth too.  The nice thing about
VRAMs is that they use only a tiny fraction of the memory array's access
bandwidth, due to their very wide internal access path.

Of course, if you're selling to the PC market and it doesn't *have* to
work well, that's another story.  I suspect that the PCers will catch
on sooner or later, though.
-- 
"Either NFS must be scrapped or NFS    | Henry Spencer at U of Toronto Zoology
must be changed."      -John Osterhout |  henry@zoo.toronto.edu   utzoo!henry