NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/pcclone/32bit/882

Internet Message Format | 1992-12-22 | 3.4 KB

Xref: sparky comp.unix.pc-clone.32bit:882 comp.unix.sysv386:17599 comp.unix.bsd:10568 comp.os.linux:21453
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
Path: sparky!uunet!spool.mu.edu!nigel.msen.com!math.fu-berlin.de!informatik.tu-muenchen.de!lrz-muenchen.de!roell
From: [e-mail] (Thomas Roell)
Subject: Re: ET4000/W32 and VESA VL-Bus
In-Reply-To: [e-mail]'s message of Sun, 20 Dec 1992 20: 14:47 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (Mr. News)
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
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: [e-mail]
das Reh springt weit,                #include <sys/pizza.h>
was soll es tun, es hat ja Zeit ...