home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / ibm / pc / hardware / 29955 < prev    next >
Encoding:
Text File  |  1992-11-15  |  4.9 KB  |  105 lines
  1. Newsgroups: comp.sys.ibm.pc.hardware
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!ira.uka.de!math.fu-berlin.de!informatik.tu-muenchen.de!roell
  3. From: roell@informatik.tu-muenchen.de (Thomas Roell)
  4. Subject: Re: [IBM] XGA-2 Specs.
  5. In-Reply-To: kaul@bcrvm1.vnet.ibm.com's message of Thu, 12 Nov 92 23:18:56 GMT
  6. References: <1992Nov11.082729.15062@hippo.ru.ac.za> <1992Nov12.231856.19708@watson.ibm.com>
  7. Sender: news@Informatik.TU-Muenchen.DE (USENET Newssystem)
  8. Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
  9. Date: Mon, 16 Nov 1992 08:21:17 GMT
  10. Message-ID: <1992Nov16.082117.15908@Informatik.TU-Muenchen.DE>
  11. Lines: 92
  12.  
  13. >   The "official" specs are"
  14. >     Max video PEL rate:    90MHz
  15. >     Max screen resolution: 1280x1024
  16. >     Max palette colors:    16.7 million (at 1024x768 - 256 colors simultaneously)
  17. >     Max palette greys:     256
  18. >     Max direct colors:     65,536 -- at 640x480 (at up to 75Hz refresh)
  19. >                   -- at 800x600 (at up to 60Hz refresh)
  20. >     Video Memory:          1 MB VRAM (which is why you only get 256
  21. >                       colors at 1024x768)
  22. >     Adapter Type:          16/32-bit bus master
  23.  
  24. I think I should followup on this ... The 16/32 bit busmastering won't
  25. help you in a ISA system, since normally the whole address space of
  26. the ISA bus (16MB) is filled with your normal DRAM ... From what I
  27. have seen this feature is just a way to force clone manufactures to
  28. waste more gates on a compatible feature that hardly anybody would use
  29. (think about busmastering in a virtual memory system).
  30.  
  31. >   >  Is it really as fast as
  32. >   >  the ATIs of this world and how does it compare to fast framebuffer
  33. >   >  cards like ET4000s -- I just want to get my appetite whetted.
  34. >
  35. >   The XGA doesn't do well on the WINMARK benchmark (pulling only about a
  36. >>   10), but that's because of the weighting of that benchmark.  On
  37. >   practical applications and programs it's much faster.  And this is
  38. >   from a guy who has an ET4000 on his home 486/33 comparing to his work
  39. >   386/25.  I believe we have a study on several Windows programs
  40. >   comparing the timings, and the XGA is very, very strong on the mix of
  41. >   operations shown by real programs.  This is especially noticable on
  42. >   OS/2 text in a window.
  43.  
  44. Hmmm ... I agree with you that MS-Windows benchmarks turn out to be
  45. real hype. They won't tell you to much. Hence here are two number the
  46. should give you some idea of the speed. I have measured solid fills of
  47. 400x400 rectangles. No pattern, just COPY mode, no clipping, no
  48. planemasking. The second test was a aligned bitblit from screen to
  49. screen, using no pattern, no clipping, no planemask, just COPY mode.
  50. These two tests show basically the rough performance of the board.
  51. What the driver writes make out of these for your application is
  52. something different:
  53.  
  54.     ET4000    XGA-2    481(8514/A clone)
  55.  
  56. Fill:    4    34    72            MegaPixels/second
  57. BitBlt:    2    14    31            MegaPixels/second
  58.  
  59. Just for reference, S3 boards with 80ns VRAMs are at the same speed as
  60. the XGA-2, and the Ultra Pro is just a little bit slower than the 481
  61. in this case. (Sorry for this 481 here, but I don't have the exact ATI
  62. numbers online)
  63.  
  64. >   As far as future enhancements, there will be some.  That's about all I
  65. >   can say :-)
  66.  
  67. Ok, here is my whishlist (from a X-Server developer, not MS-Windows ;-)):
  68.  
  69.     - reintroduction of some sort of command queue. Right now you
  70.       have to wait for the XGA to finish it's operation before you
  71.       can write to the XGA registers to set up a new one. That
  72.           means you cannot have the same concurrency as for the 8514/A
  73.           where you just could stuff everything in the command queue,
  74.       and let the 8514/A work pretty much interleaved with the
  75.       driver.
  76.  
  77.     - some sort of HW pattern registers. Right now if you do a
  78.       patterned fill, the pattern is in VRAM. Hence you have
  79.       normal bitblit cycles to do the fill (i.e. RMW). If you had
  80.       pattern registers, you wouldn't have to relead the pattern
  81.       from VRAM, and if the rasteroperation would be a simple copy
  82.       mode, then normal write cycles would be all that's necessary
  83.  
  84.     - extend the XGA internally at least to use 16 bit
  85.       corrdinates. If you draw for exaple lines in a drive that
  86.       allows you 16bit coordnates, you cannot simply use HW
  87.       clipping, since the XGA has only 12bit coordinates (and
  88.       wraparound for huge coordinates would occure). Hence you
  89.       have to do at least SW preclipping against the device coordinate
  90.       space, which does cost unecessary time.
  91.  
  92.     - there is no way to copy a single plane of pixels of a n-bit deep
  93.       image to another plane in the same image. This was possible
  94.       in the good old 8514/A (using the read-mask).
  95.     
  96.     - 1280x1024 non-interlaced at 256 colors (read: support for 2MB
  97.       VRAM)
  98.  
  99. - Thomas
  100. --
  101. -------------------------------------------------------------------------------
  102. Das Reh springt hoch,                 e-mail: roell@sgcs.com
  103. das Reh springt weit,                #include <sys/pizza.h>
  104. was soll es tun, es hat ja Zeit ...
  105.