home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.pc-clone.32bit:883 comp.unix.sysv386:17604 comp.unix.bsd:10580 comp.os.linux:21487
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!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.
-