From: roell@informatik.tu-muenchen.de (Thomas Roell)
Subject: Re: [IBM] XGA-2 Specs.
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
Date: Mon, 16 Nov 1992 08:21:17 GMT

>   The "official" specs are"
>     Max video PEL rate:    90MHz
>     Max screen resolution: 1280x1024
>     Max palette colors:    16.7 million (at 1024x768 - 256 colors simultaneously)
>     Max palette greys:     256
>     Max direct colors:     65,536 -- at 640x480 (at up to 75Hz refresh)
>				   -- at 800x600 (at up to 60Hz refresh)
>     Video Memory:          1 MB VRAM (which is why you only get 256
>				       colors at 1024x768)
>     Adapter Type:          16/32-bit bus master

I think I should followup on this ... The 16/32 bit busmastering won't
help you in a ISA system, since normally the whole address space of
the ISA bus (16MB) is filled with your normal DRAM ... From what I
have seen this feature is just a way to force clone manufactures to
waste more gates on a compatible feature that hardly anybody would use
(think about busmastering in a virtual memory system).

>   >  Is it really as fast as
>   >  the ATIs of this world and how does it compare to fast framebuffer
>   >  cards like ET4000s -- I just want to get my appetite whetted.
>
>   The XGA doesn't do well on the WINMARK benchmark (pulling only about a
>>   10), but that's because of the weighting of that benchmark.  On
>   practical applications and programs it's much faster.  And this is
>   from a guy who has an ET4000 on his home 486/33 comparing to his work
>   386/25.  I believe we have a study on several Windows programs
>   comparing the timings, and the XGA is very, very strong on the mix of
>   operations shown by real programs.  This is especially noticable on
>   OS/2 text in a window.

Hmmm ... I agree with you that MS-Windows benchmarks turn out to be
real hype. They won't tell you to much. Hence here are two number the
should give you some idea of the speed. I have measured solid fills of
400x400 rectangles. No pattern, just COPY mode, no clipping, no
planemasking. The second test was a aligned bitblit from screen to
screen, using no pattern, no clipping, no planemask, just COPY mode.
These two tests show basically the rough performance of the board.
What the driver writes make out of these for your application is
something different:

	ET4000	XGA-2	481(8514/A clone)

Fill:	4	34	72			MegaPixels/second
BitBlt:	2	14	31			MegaPixels/second

Just for reference, S3 boards with 80ns VRAMs are at the same speed as
the XGA-2, and the Ultra Pro is just a little bit slower than the 481
in this case. (Sorry for this 481 here, but I don't have the exact ATI
numbers online)

>   As far as future enhancements, there will be some.  That's about all I
>   can say :-)

Ok, here is my whishlist (from a X-Server developer, not MS-Windows ;-)):

	- reintroduction of some sort of command queue. Right now you
	  have to wait for the XGA to finish it's operation before you
	  can write to the XGA registers to set up a new one. That
          means you cannot have the same concurrency as for the 8514/A
          where you just could stuff everything in the command queue,
	  and let the 8514/A work pretty much interleaved with the
	  driver.

	- some sort of HW pattern registers. Right now if you do a
	  patterned fill, the pattern is in VRAM. Hence you have
	  normal bitblit cycles to do the fill (i.e. RMW). If you had
	  pattern registers, you wouldn't have to relead the pattern
	  from VRAM, and if the rasteroperation would be a simple copy
	  mode, then normal write cycles would be all that's necessary

	- extend the XGA internally at least to use 16 bit
	  corrdinates. If you draw for exaple lines in a drive that
	  allows you 16bit coordnates, you cannot simply use HW
	  clipping, since the XGA has only 12bit coordinates (and
	  wraparound for huge coordinates would occure). Hence you
	  have to do at least SW preclipping against the device coordinate
	  space, which does cost unecessary time.

	- there is no way to copy a single plane of pixels of a n-bit deep
	  image to another plane in the same image. This was possible
	  in the good old 8514/A (using the read-mask).
	
	- 1280x1024 non-interlaced at 256 colors (read: support for 2MB
	  VRAM)

- Thomas
--
-------------------------------------------------------------------------------
Das Reh springt hoch, 				e-mail: roell@sgcs.com
das Reh springt weit,				#include <sys/pizza.h>
was soll es tun, es hat ja Zeit ...