From: fangchin@leland.Stanford.EDU (Chin Fang)
Subject: Re: What is the fastest 80x86 SVR4 X window hardware?
Organization: DSG, Stanford University, CA 94305, USA
Date: Wed, 9 Sep 92 19:34:19 GMT

In article <1992Sep9.153201.18582@cbnewsj.cb.att.com> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>In article <BuB644.GCw@gator.rn.com> larry@gator.rn.com (Larry Snyder) writes:
>> jdc@tropix.uucp (Jim Cronin) writes:
>> 
>> >As the subject line says, what is the "fastest" X-windows display
>> >for a 80386 or 80486 running SVR4 Unix?  Are there particular
>> >chipsets (ET4000 or 8414 for example) that are really great or
>> >really bad?  Are there any boards out there that are much better
>> >or much worse?  Are there any that stand out at low resolution
>> >but slow down at higher resolutions?  And how about dual-ported
>> >video ram?

Depending whether you want free/(with src) or want commerical implementation.
As David pointed out below.  Go with VRAM helps quite much in many instances.
ET4000 is a dumb frame buffer, but if you can find local bus card using
this chipset, it should be sufficient for many daily work.  

>> How about the ATI ultra?  With Dell SVR4 something like 86,000
>> xstones is delivered using their X11R5 making it faster than
>> many sparcs..

I am running Dell's SVR4 issue 2.2 on a 20Mhz 386 with 8 megs right
now.  at work. A few days ago, I put in an early model ATI 8514
Graphics Ultra with MS compatible 3button bus mouse into this box just
for curiosity.  Well, the results were pleasing, but due to the fact
that this box has only 8 MEGs, and the default Dell kernel is fat
(~1.8 Meg, I haven't got around to trim it yet, my work load these
days is too heavy :( so disk swapping caused a lot slow down.  But the
potential of the ATI board is really obvious.

BTW, the early model of ATI Graphics Ultra (with 1MEG VRAM) only offers
75Mhz as the highest dot clock.  This is really confining.  As dictated
by the basics of video timing, if one wants 70Hz or greater refresh rate
then only 0.7 Meg pixel is possible (eg. 1024x768).  More on this below.

>A big piece of the puzzle is "do you want free X, with source?"  If this
>is a concern for you, then ET4000 is the best you are going to do.  An
>Orchid ProDesigner IIs in my 486/33 box is currently doing 11.6k xStones
>with XFree86 1.1 (beta - expected release at the end of the month).  We
>are hoping to eventually squeeze a bit more out, but that's the about the
>best you're going to do.

David, have you got a local bus ET4000 card for testing yet?  I imagine
the higher bandwidth and higher clock should help.  I don't have one thou.

[the rest deleted]

In general, when ask X graphics performance, the desired resolution should
be made clear.  Various graphics hardware combo can support different 
resolution at different performace levels.  Here are some simple rule
of thumb myself use to evaluate hardware quality for high-res work (i.e.
at least one Meg pixels)

Assuming you want X% of Meg pixels as your resolution (e.g. 
1024x768 ~ 70% meg pixels, 1152x900 ~ 90% meg pixels, 1120x830 ~ 80% meg
pixels etc.) and assuming that you always want 70 Hz vertical refresh
rate or higher for non-flickering display, then the following rules
should hold for most instances (only variable frequency monitors are 
considered)

(1) the highest dot clock available from your video adapter should
    be X Mhz or higher, (e.g. if X = 70, then 70 Mhz should be available),
(2) the upper limit of your monitor's horizontal sync frequency should
    be at least the above dot clock /(0.8 x your desired horizontal resolution)

I think if you go by these two rules in selecting your video subsystem
components, with a sufficiently generous budget for a coprocessor
assisted board (for commerical implementations, of course), then you
should be fine in most instances.

Regards,

Chin Fang
fangchin@leland.stanford.edu
ps.  Please don't reply to my Stanford account, as I have graduated in 
     June and am now working in Los Angeles as a Member Technical Staff again
  
Newsgroups: comp.unix.sysv386