Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!bruce!labtam!graeme
From: graeme@labtam.labtam.oz (Graeme Gill)
Newsgroups: comp.arch
Subject: Re: Let's pretend
Summary: Went fishing, and caught ....
Keywords: Intel, 586, windows
Message-ID: <5813@labtam.labtam.oz>
Date: 20 Dec 90 04:02:40 GMT
References: <3042@crdos1.crd.ge.COM> <450@lysator.liu.se> <5800@labtam.labtam.oz> <3066@crdos1.crd.ge.COM>
Organization: Labtam Australia, Melbourne, Australia
Lines: 50

In article <3066@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
> In article <5800@labtam.labtam.oz> graeme@labtam.labtam.oz (Graeme Gill) writes:
> 
> |     The answer to this is the usual RISC vs CISC arguments. Why have very
> | complicated hardware, that tends to be locked into a particular implementation
> | of windowing etc. , when with a little bit of effort on the window library
> | programmers part you can get the same performance with more general hardware
> 
>   When this lovely generalized system can perform at a reasonable rate,
> then that's fine. Until then users will want hardware boost because it's
> more pleasant to use, companies will want it because it's more
> productive.
> 
>   A display system isn't fast enough until it has to be slowed down to
> avoid overrunning the input bandwidth of the eye. Until then people will
> want more, and today that means some hardware assists. In truth you
> *can't* write software as fast as dedicated hardware, with any amount of
> effort, much less "a little bit."
> -- 

    I'm happy to say you are wrong. How does 208 Mbit/sec fill rate sound ?
Or a 100 Mbit/sec blt rate sound ? That's equivalent to 30 frames a second
fill rate on an 8 bit colour 1024 x 800 system, all done in software, no
hardware support. It only took me a few weeks work, to code up the routines,
and our customers don't have to know anything about it, since all they
see is a standard X11 interface. This isn't pie in the sky, we've been 
shipping for over 12 months.  If we'd used available graphics chips like
the 34010, 82786, 63484 etc, rather than a general purpose CPU like the
80960 (or the 29000), then the terminals would have been a lot slower,
with little or no possibility of fixing the operations those chips don't
support very well. In addition, we don't need another CPU chip as well
to handle ethernet i/o, X protocol processing etc. You will notice
that all the standalone 34010 systems have a 80186 or something in the
box as well.
    Our customers enjoy using the terminals, because they are noticeably
faster and more interactive than products based on available graphics
chips.
    This is likely to be the shape of the future. Notice that the Apple
Mac accelerator cards are based on 29000 chips, and that a number of
accelerator cards for the IBM PCs are starting to appear, based on
RISC CPUs rather than graphics chips.
    As I said before, there is definitely room for hardware assist, but
a bit of general purpose CPU goes a long way, especially in cost
effective systems.
	Oh, and bye the way, a lot of the operations are so fast now,
that they have to be slowed down in order to see whats going on.

	Graeme Gill
	Electronic Design Engineer.
	Labtam Australia