Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA5482 ; Fri, 01 Jan 93 01:46:42 EST Xref: sserve comp.unix.pc-clone.32bit:811 comp.unix.sysv386:26496 comp.unix.bsd:9316 comp.os.linux:20287 Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!sdd.hp.com!nigel.msen.com!math.fu-berlin.de!informatik.tu-muenchen.de!lrz-muenchen.de!roell From: roell@informatik.tu-muenchen.de (Thomas Roell) Subject: Re: ET4000/W32 and VESA VL-Bus In-Reply-To: bhenning@wimsey.bc.ca's message of Sun, 20 Dec 1992 20: 14:47 GMT Message-ID: <1992Dec22.213014.25590@news.lrz-muenchen.de> Sender: news@news.lrz-muenchen.de (Mr. News) Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany References: <BzBEI1.CH@aeon.in-berlin.de> <1992Dec20.153314.24148@Informatik.TU-Muenchen.DE> <BzKqwn.5vA@wimsey.bc.ca> Date: Tue, 22 Dec 1992 21:30:14 GMT Lines: 56 >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. This raises the intresting question how much is exactly left over. Let's do some computations for the currently common case of 1024x768 in 60Hz (i.e. 65MHz dot-clock). First a few assumptions (which seem to be realistically for the WD90C31 (where I looked deeper into the databook)): a) 100MB/sec total bandwidth (fast page mode) b) 32 bytes internal buffer for screen refresh c) a RAS cycle needs twice the time of a CAS cycle. d) all accesses are 32bit wide. Hence we have 25 * 10**6 accesses/sec by using (tRAS + 8 * tCAS) / 8 = 10 / 8* tCAS timeunits, which would mean that tCAS is 32ns. Ok, for a 65MHz dot-clock we need during display a pixel every 15ns. That means every 15ns * 32 we have to reload the internal buffer, which is every 480ns. For reloading we need 32ns * 10 = 320ns. In fact we now have 160ns for the graphics engine left. Now assume that all accesses in this perion can be fast page mode, then we can do 3 accesses (we have to do one RAS cycle ...), which is that for every 480ns we can get 12 bytes, which then is totally 25MB/sec. Unless I made a serious computing mistake this means that we get only 25MB/sec on a 100MB/sec bandwidtg system if a dot-clock of 65MHz is used. Now lets go on, and say we use a 75MHz dotclock to get the 70Hz high refresh rate. Here we need every 420ns a reload of the buffer. Then we have only 100ns for the graphics engine left. That says we can (by rounding things a little bit up) get only 4 bytes over a 480ns period, which is 8.3 MB/sec. Actually this computation doesn't include the fact the the real active period is only 80% to 90% of the while time spent. Hence one could add about 10% additional bandwidth to the numbers I computed here. But what they show pretty clearly is that the bandwidth left after the screen refresh for the graphics engine is pretty small, even if the total available bandwidth (total bandwidth - screen refresh bandwidth) would be much higher. Note also that in a VRAM based system with the same characteristics we would have roughtly the whole 100MB/sec available for graphics operations. - Thomas -- ------------------------------------------------------------------------------- Das Reh springt hoch, e-mail: roell@sgcs.com das Reh springt weit, #include <sys/pizza.h> was soll es tun, es hat ja Zeit ...