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