Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA5447 ; Thu, 24 Dec 92 10:00:28 EST
Xref: sserve comp.unix.pc-clone.32bit:805 comp.unix.sysv386:26491 comp.unix.bsd:9300 comp.os.linux:20255
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!ames!pacbell.com!charon.amdahl.com!amdahl!JUTS!griffin!gab10
From: gab10@griffincd.amdahl.com (Gary A Browning)
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
Subject: Re: ET4000/W32 and VESA VL-Bus
Message-ID: <003g02AH30U501@JUTS.ccc.amdahl.com>
Date: 23 Dec 92 05:03:36 GMT
References: <BzBEI1.CH@aeon.in-berlin.de> <1992Dec20.153314.24148@Informatik.TU-Muenchen.DE> <BzKqwn.5vA@wimsey.bc.ca>
Sender: netnews@ccc.amdahl.com
Organization: Amdahl Corporation
Lines: 23
In article <BzKqwn.5vA@wimsey.bc.ca>, bhenning@wimsey.bc.ca (Bill
Henning) writes:
> The problem with DRAM based accelerators, even if they get 160Mb/sec
> bandwidth out of the DRAM's is that the bandwidth is not
> random-access,
> but is rather a result of page mode (or static column, or nibble
> mode)
> DRAM cycles, therefore if you are using say 110Mb of bandwidth to
> feed a 1280x1024x8 display, the theoretically 50Mb/sec bandwitdh
> left over will actually be more like 10-20Mb/sec, as most graphics
> operations will not be able to take full advantage of page mode,
> even if the bus interface to the local bus supports it.
>
> Bill
Don't overlook bus width in your analysis. The W32 sounds like it is 32 bit
wide path instead of the 8 (16?) - bit wide path of the standard ET4000.
This would quadruple (double?) the bandwidth of any type of ram access.
--
Gary Browning | Exhilaration is that feeling you get just after a
| great idea hits you, and just before you realize
| what is wrong with it.