Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ucsdhub!hp-sdd!apollo!nelson_p
From: nelson_p@apollo.HP.COM (Peter Nelson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: VGA Card Recommendation for Zenith Flat Screen
Message-ID: <4959baeb.20b6d@apollo.HP.COM>
Date: 22 Mar 90 18:50:00 GMT
Sender: root@apollo.HP.COM
Distribution: usa
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 51





  mcdonald@aries.scs.uiuc.edu (Doug McDonald) posts..

:>  Now that PC's are entering the workstation-range of MIPS (33MHz
:>  386's are 5-7 MIPS, 486's are claiming 10-15 MIPS) it's about
:>  time to get workstation-range graphics.  Intelligent graphics
:>  processors are the way that workstations do it, and its the way PC's 
:>  should (and eventually will) do it too.   It's not a question of
:>  "if" but "when".  How many more universally-supported low-end
:>  (CGA/EGA/VGA) standards or poorly-supported high-end standards
:>  will we have to endure before we get a universally supported 
:>  high-end standard?
:>
:BUT .... it is vitally important that the frame buffer be accessible to
:the main CPU. Otherwise there is going to be some fairly large
:set of things that the programmer wants to do that happens to be
:SLOW as molasses when done using whatever primitives the graphics
:processor supports. Try blits from memory to screen on a Silicon
:Graphics Iris IV, for example. 

   True, but it doesn't have to be this bad.   One approach is to
   have a fast blt between the CPU's RAM and the display memory.  
   I'm not familiar with SGI's architecture so I don't know what
   the issues are with them.

   Probably a better approach is to map the display memory into
   the processor's address space as they do now, but have a parallel
   processor to do the graphics.  If you want to draw a line on the 
   screen, instead of having the CPU do a Bresenham walk, or whatever,
   and calculate and draw the pixels one-at-a-time, it would just 
   tell the coprocessor "draw a line from p1 to p2".  The coprocessor
   would do all the work and acess the display memory via DMA while
   the CPU would start working on the next item.  But there would
   be nothing to stop the CPU from accessing the frame buffer directly 
   if it needed to.   An improvement on this design is to map it into 
   the CPU's address space *when you need it*, or to selectively 
   map parts of it in.  

   Forcing the CPU to have to do all the work, on a pixel-by-pixel
   basis as it does now will become a big problem as screen reso-
   lutions get higher.  1024X768 is over 2.5 times as many pixels
   as 640X480.  And if users start expecting smooth-shaded or
   hidden-surface-removed images for greater realism there's 
   almost no way this can be done with reasonable performance
   with current PC graphics architectures.  

                                                ---Peter