home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / os2 / misc / 25503 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!agate!darkstar.UCSC.EDU!ucscb.UCSC.EDU!urbndv8
  2. From: urbndv8@ucscb.UCSC.EDU (Bleeding Rivets)
  3. Newsgroups: comp.os.os2.misc
  4. Subject: Re: ati graphics ultra
  5. Date: 25 Jul 1992 02:46:41 GMT
  6. Organization: University of California; Santa Cruz
  7. Lines: 56
  8. Distribution: comp
  9. Message-ID: <14qfahINNp0g@darkstar.UCSC.EDU>
  10. References: <1992Jul24.1480.22900@dosgate>
  11. NNTP-Posting-Host: ucscb.ucsc.edu
  12.  
  13.  
  14. In article <1992Jul24.1480.22900@dosgate> "roger ramsey" <roger.ramsey@canrem.com> writes:
  15. >Man Kit Tang wrote on 07-22-92 regarding ATI GRAPHICS ULTRA:
  16. >
  17. >MK>Well, for an AT bus based coprocessed grahics card.  Most of the 
  18. >MK>advantage gain does come from reducing bandwidth requirement of the AT 
  19. >MK>bus.  The Mach 8 does some graphics primitive pretty well, but for that 
  20. >MK>matter, a 486 is not bad either.
  21. >
  22. >I think you'll find that 1024x768x256 on a 386/33 with a Graphics Ultra 
  23. >will be faster than a 486/33 with a plain dumb frame buffer SVGA card.
  24.  
  25.  
  26.  
  27. Changing CPU's to one that is twice as fast might give you ~ 10% speed
  28. improvement or so, if you already have a CPU fast enough to keep the bus
  29. busy; i.e. from a 386/33 to a 486/33.
  30. This proves to me it's not processor power that makes the real difference.
  31.  
  32. >
  33. >MK>So, one more time, the problem of HIGH resolution graphics 
  34. >MK>performance of most PC compatibles with AT based controller is the 
  35. >MK>limited bandwidth of the AT bus.
  36. >
  37. >From the point of view that, using your above example, the 486 would have 
  38. >to calculate every pixel and then send it across the bus rather than a 
  39. >series of instructions to the card, then yes the bus becomes a limiting 
  40. >factor.
  41. >
  42. >Roj
  43. >
  44.  
  45. Your original statement was that the purpose of coprocessed video cards
  46. was to take the load off the CPU.  I find this hard to believe in light of
  47. the fact that even a much faster CPU won't improve graphics speed much.
  48. If the CPU were being taxed by calculating pixels, and this is what kept
  49. video speed down, then a 2x faster CPU should draw a screen 2x as fast,
  50. and this is definitely not the case.
  51.  
  52. (The above assumes both CPU's are using a dumb video card; with a coprocessed
  53. video card the bottleneck (in some cases) might once again be the CPU, since
  54. the bus traffic would be so greatly diminished.)
  55.  
  56. > ~ WinQwk 2.0 a#473 ~ Reality is for those who can't handle Star Trek.
  57. >--
  58. >Canada Remote Systems  - Toronto, Ontario/Detroit, MI
  59. >World's Largest PCBOARD System - 416-629-7000/629-7044
  60.  
  61.  
  62. -- 
  63. "The possessed's mad speech is the higher wisdom of the world, since it is 
  64. human...Why have we not yet acquired this insight in relation to the world
  65. of the free will?  Because outwardly we are the masters of madness, because
  66. the insane are violated by us, and we hinder them from living according to
  67. their ethical laws...Now we must endeavor to overcome the dead point in our
  68. realtionship to insanity."       --Wieland Herzfelde, 1914
  69.