Path: utzoo!attcan!uunet!clyde.concordia.ca!mcgill-vision!snorkelwacker!bu.edu!orc!decwrl!shelby!agate!bionet!ames!sun-barr!newstop!sun!eng.sun.com
From: david@eng.sun.com (6. Do you resent the efforts of others to tell you what to do?)
Newsgroups: comp.arch
Subject: Re: 386 machines are workstations? (Sun/386i)
Message-ID: <136491@sun.Eng.Sun.COM>
Date: 1 Jun 90 01:37:00 GMT
References: <136288@sun.Eng.Sun.COM> <1990May30.041648.9063@ico.isc.com>
Sender: david@sun.Eng.Sun.COM
Lines: 28

In article <1990May30.041648.9063@ico.isc.com> rcd@ico.isc.com (Dick Dunn)
writes:
>david@eng.sun.com  writes:
>> If you look at MIPS and memory bandwidth, a 386 class CPU driving a 1 Mb
>> dumb frame buffer is pretty marginal.  You have to tune the window system
>> code very carefully to get snappy interactive performance, and this was
>> never done for SunView on the 386i.

>The experience of the folks working on X at Interactive seems to be quite
>the opposite:  If you've got a dumb frame buffer, the limiting factor is
>the video memory speed.

That's because they're working with DRAM frame buffers on a slow PC bus.
The Sun-386i in question has a well designed VRAM frame buffer on a fast
bus.  Under these conditions it's hard to write code which will allow the
386 to saturate the buffer buffer (especially when you want to write it in
C and you don't have a very good C compiler).

I should also have mentioned that SunView performance improved quite a bit
from the initial 386i release ("4.0.0") to 4.0.1 to 4.0.2.

>Remember that a dumb frame buffer is
>not just a hunk of memory; it's a hunk of *dual-ported* memory...

Ever hear of VRAMs?

-- 
David DiGiacomo, Sun Microsystems, Mt. View, CA  david@eng.sun.com