home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / ibm / pc / hardware / 21798 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.2 KB
  1. Xref: sparky comp.sys.ibm.pc.hardware:21798 comp.sys.intel:1497 comp.sys.ibm.pc.misc:11468
  2. Path: sparky!uunet!math.fu-berlin.de!zrz.tu-berlin.de!gmdtub!bigfoot!tmh
  3. From: tmh@doppel.first.gmd.de (Thomas Hoberg)
  4. Newsgroups: comp.sys.ibm.pc.hardware,comp.sys.intel,comp.sys.ibm.pc.misc
  5. Subject: Re: More on Local Bus - What about Unix?? S3 vs.
  6. Message-ID: <TMH.92Aug14013048@doppel.first.gmd.de>
  7. Date: 13 Aug 92 23:30:48 GMT
  8. References: <0105010F.ac48r9@mprnews.mpr.com>
  9.     <1992Aug10.092255.118@vulcan.resmel.bhp.com.au>
  10.     <Bss82v.LJM@usenet.ucs.indiana.edu>
  11.     <ADAMS.92Aug13004812@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
  12.     <1992Aug13.064156.2539@Informatik.TU-Muenchen.DE>
  13. Sender: news@bigfoot.first.gmd.de
  14. Followup-To: comp.sys.ibm.pc.hardware
  15. Organization: GMD-FIRST, Berlin
  16. Lines: 57
  17. In-reply-to: roell@informatik.tu-muenchen.de's message of 13 Aug 92 06:41:56 GMT
  18.  
  19. In article <1992Aug13.064156.2539@Informatik.TU-Muenchen.DE> roell@informatik.tu-muenchen.de (Thomas Roell) writes:
  20.  
  21.    >1) Without a coprocessor, graphic in a PC means bit manipulation by CPU.
  22.    >This may eat up most of the available bandwidth.
  23.  
  24.    Yes, but in localbus designs you have the bandwidth available. And if
  25.    you have a simple framebuffer directly attached to the CPU it is
  26.    *very* fast.
  27.  
  28.    >2) As a coprocessor allows to use protocols at a much higher level,
  29.    >like X or Phigs, communication overhead _shrinks_ tremendously.
  30.    >This has been proven with PC-graphic adapters running Xserver themselves,
  31.    >no CPU had to write to video memory anymore.
  32.  
  33.    Well, then you hit another effect. The CPUs are getting faster faster
  34.    than the graphics chips do. Like the 34020 is about 6 MIPS, while a
  35.    486 is much higher (think around 20 on a 486/50). That means that the
  36.    main CPU is just waiting for the Graphics board the do something ...
  37.    Another performance wall you hit is the communication between adaptor
  38.    and CPU. Normally they want to have all graphics requests in a special
  39.    format encoded, which means the 486 is quite busy to translate the
  40.    users requests. And not to forget you have to go over a bus, which
  41.    means you have to do busarbitrating (like queue polling).
  42.  
  43.    My personal oppinion is that a graphics chips should have the best of
  44.    both worlds:
  45.  
  46.        a) Memory mapped, both framebuffer and graphics engine
  47.  
  48.        b) The GE should have a deep queue for commands
  49.  
  50.        c) The GE should be optimized to do only simple commands, but
  51.           these hardcoded in silicon to drive the RAMs at threir top speed.
  52.  
  53.           The commands would be simply COPY_RECT, FILL_RECT,
  54.           DRAW_LINE.
  55.  
  56.        d) Let the rest do the main CPU, which has the horsepower for
  57.           clipping and rendering in lowend systems.
  58.  
  59.    An approch like this will buy you much more than a highpriced special
  60.    Graphics board. Or why do you think are these RISCy GEs faster under X
  61.    than the 340x0 based boards ?
  62.  
  63.    - Thomas
  64.  
  65. Why don't you just name it? It's called the GX accellerator and sold
  66. by SUN (now that we have local bus, why doesn't somebody go clone
  67. it?).
  68. ---
  69. Thomas M. Hoberg   | Internet: tmh@first.gmd.de
  70. 1000 Berlin 41     |           tmh@cs.tu-berlin.de
  71. Wielandstr. 4      |
  72. Germany            | BITNET:   tmh@tub.bitnet 
  73. +49-30-851-50-21   |
  74.  
  75.  
  76.