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

Internet Message Format | 1992-12-27 | 4.0 KB

Xref: sparky comp.unix.pc-clone.32bit:907 comp.unix.sysv386:17630 comp.unix.bsd:10666 comp.os.linux:21858
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
Path: sparky!uunet!van-bc!bhenning
From: [e-mail] (Bill Henning)
Subject: Re: ET4000/W32 and VESA VL-Bus
Organization: Wimsey Information Services
Date: Mon, 28 Dec 1992 02:01:47 GMT
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 62

In article <[e-mail]> [e-mail] (Thomas Roell) writes:
>>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
>...
>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.
>
Agreed, given
  (a) 32 bit CPU access to the video buffer (local bus)
  (b) motherboard chipset support for RAS/CAS/CAS/CAS three-consecutive
      word access cycle
>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.
Potentially much worse. If the system will not support (b) above, then
you could only get about 8.3Mb/sec
>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.
Could be as low as 2.8Mb if CAS only read cycles are not supported.
>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.
And let us not forget the AT bus... if the VGA card does not support
16 bit accesses, at 70Hz, 75Mhz dot clock, it could be as low as 1.4Mb
and as low as 0.7Mb if only eight bit access is suppoted to the buffer.
>Note also that in a VRAM based system with the same characteristics we
>would have roughtly the whole 100MB/sec available for graphics
>operations.
>...
>Das Reh springt hoch,                 e-mail: [e-mail]
Agreed, if I remember correctly, on a VRAM based buffer you may have
contend for access approx. 1/1024 cycles (negligible) - so on a proper
local bus motherboard, which supports page-mode or similar access to
a VRAM based buffer, you may have 100Mbytes/sec access to the video
buffer - which would make for a fairly fast X server if the software
took advantage of it. Actually, I am quite pleased with the performance
of XFree on my 386/40 with a Genoa 7900 (75Mhz dot clock, 13Mhz AT bus)
quite usable for X, but not quite like the HP 9000/720 at work.

Bill