home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / ibm / pc / hardware / 21754 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.3 KB
  1. Xref: sparky comp.sys.ibm.pc.hardware:21754 comp.sys.intel:1490 comp.sys.ibm.pc.misc:11445
  2. Newsgroups: comp.sys.ibm.pc.hardware,comp.sys.intel,comp.sys.ibm.pc.misc
  3. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!zrz.tu-berlin.de!math.fu-berlin.de!news.th-darmstadt.de!adams
  4. From: adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Hans Adams)
  5. Subject: Re: More on Local Bus - What about Unix?? S3 vs. 
  6. Sender: news@news.th-darmstadt.de (The Usenet-News System)
  7. Message-ID: <ADAMS.92Aug13163126@pdv3.pdv3.fmr.maschinenbau.th-darmstadt.de>
  8. In-Reply-To: roell@informatik.tu-muenchen.de's message of Thu, 13 Aug 1992 06: 41:56 GMT
  9. Date: Thu, 13 Aug 1992 16:31:26 GMT
  10. References: <0105010F.ac48r9@mprnews.mpr.com>
  11.     <1992Aug10.092255.118@vulcan.resmel.bhp.com.au>
  12.     <Bss82v.LJM@usenet.ucs.indiana.edu>
  13.     <ADAMS.92Aug13004812@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
  14.     <1992Aug13.064156.2539@Informatik.TU-Muenchen.DE>
  15. Nntp-Posting-Host: pdv3.fmr.maschinenbau.th-darmstadt.de
  16. Organization: TH-Darmstadt
  17. Lines: 59
  18.  
  19. In article <1992Aug13.064156.2539@Informatik.TU-Muenchen.DE> roell@informatik.tu-muenchen.de (Thomas Roell) writes:
  20.  
  21. A) I regard your X11 port as one of the best available for standard
  22. graphic adaptors in PC world ! 
  23.  
  24. >   >1) Without a coprocessor, graphic in a PC means bit manipulation by CPU.
  25. >   >This may eat up most of the available bandwidth.
  26.  
  27. >   Yes, but in localbus designs you have the bandwidth available. And if
  28. >   you have a simple framebuffer directly attached to the CPU it is
  29. >   *very* fast.
  30.  
  31. .... but in no way special suited for bitmanipulation and clipping ...
  32.  
  33. >   >2) As a coprocessor allows to use protocols at a much higher level,
  34. >   >like X or Phigs, communication overhead _shrinks_ tremendously.
  35. >   >This has been proven with PC-graphic adapters running Xserver themselves,
  36. >   >no CPU had to write to video memory anymore.
  37.  
  38. >   Well, then you hit another effect. The CPUs are getting faster faster
  39. >   than the graphics chips do. Like the 34020 is about 6 MIPS, while a
  40. >   486 is much higher (think around 20 on a 486/50). That means that the
  41. >   main CPU is just waiting for the Graphics board the do something ...
  42.  
  43. NO! Compare current architectures to current architectures, not
  44. outdated ones like 34020 [ >>> 20 << ]. BTW: Does not an 34c050 exist
  45. meanwhile?
  46.  
  47. >   Another performance wall you hit is the communication between adaptor
  48. >   and CPU. Normally they want to have all graphics requests in a special
  49. >   format encoded, which means the 486 is quite busy to translate the
  50. >   users requests. And not to forget you have to go over a bus, which
  51. >   means you have to do busarbitrating (like queue polling).
  52.  
  53. Common architectures use real double ported memory or fifos to
  54. interface client [ports] to server [engine]. No need for arbitration.
  55. There is no special encoding necessary, as X uses a prescribed protocol 
  56. anyway.
  57.  
  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.  
  64. First, 34020s are outdated...
  65. Second, those RISCies outperforming  free available graphic processors
  66. employ their own property one, like
  67.     - GSX board by SUN,
  68.     - graphic engine and clipping pipeline by SGI for SGI-4Dxxx.
  69.  
  70. Or why do you think sell fast graphic subsystems like sliced bread,
  71. like those from Raythenon?
  72.  
  73. best adams
  74.  
  75.  
  76.  
  77.  
  78.