From: tmh@keks.first.gmd.de (Thomas Hoberg)
Newsgroups: comp.windows.x.i386unix
Subject: Re: 32K or 16M colours?
Date: 20 Dec 92 22:54:23 GMT
Organization: GMD-FIRST, Berlin
In-reply-to: dwex@cbnewsj.cb.att.com's message of 20 Dec 92 00:04:26 GMT

In article <1992Dec20.000426.21774@cbnewsj.cb.att.com> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
   In article <linda.724803368@minnie> linda@cs.su.oz.au (Linda Distributed Language) writes:
   > Is anybody working on X servers for cards which display 32K or 16M colours,
   > like the 2theMax et4000 based card and other extended et4000 cards?
   > (the 2theMax will do up to 1280x1024x16, 1024x768x256, 800x600x32K)
[...]
   Here's what I know about it:

	   1) The cfb code with X11R5 was only tested at 8 bits, and is
	      known to need work to make it work with other depths.
I don't know what X11R5 was tested on, but any power of 2 is ok as far
as CFB is concerned. I did an X11R4 port to a 1920x1024 HDTV true
color frame buffer two years ago and started with CFB code. Actually
CFB isn't all that useful for depths greater than 8-Bit, because it
uses some gyriations to avoid extra memory and frame buffer references
and tries to work on as many pixels as possible at the same time. On a
packed pixel true color display that code (which was derived from MFB
where it offers the most significant speed improvement) does more harm
than good.

	   2) The assembler parts of the frame-buffer code in XFree86 were
	      designed for 8-bits, and will also need work.
Definitely, since one of the main reasons for it's existence is the
banked nature of SVGA cards.

	   3) X11R6 will likely have 8-bit, 16-bit, and 24-bit frame-buffer
	      code.
I doubt that it will support banked displays nicely.

	   4) 24-bit SVGA is going to require a LOT of work (perhaps an
	      entire new framebuffer driver), because the 24-bit framebuffers
	      on most system (and the Xsun24 code I looked at) assume that
	      the 24-bits are aligned on 32-bit boundaries, and the 24-bit
	      SVGA's are aligned on 24-bit boundaries (think of the pixel-
	      addressing complexities here).
If they are (which I doubt) they would be riciculously slow. Also
since they usually trade resolution for pixel depth that means X on
something like 640x480 (yuck!).

	   5) The 16- and 24-bit SVGA modes are SLOW (1/2 and 1/3 the speed
	      of the 8-bit modes, respectively).
Since they trade resolution for pixel depth, the speed differences
shouldn't be that high (except for horizontal lines).

>   I would expect that a 16-bit server could be done by a dedicated group
>   without too much headache (lots of use of the XTEST suite will help :->).
If the SVGAs weren't banked, all it would take is the editing of a
couple of macros and a recompile of CFB (or almost). Even with the
X386 version that came with X11R5 it shouldn't be too much work (no
assembler except for bank switching), although the initialization
stuff would be beyond me (lacking the appropriate documentation).

>   The 24-bit stuff is going to be much, much worse.
But only if they really pack those pixels on adjacent addresses. It
would completely break CFB and as you said, the work involved would be
horrendous...

   --
   David Wexelblat <dwex@mtgzfs3.att.com>  (908) 957-5871
   AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ  07748

   "The meaning of life?  That's simple.  Try to be happy, try not to hurt
    other people, and hope to fall in love."  -- Mallory Keaton

I can only underline Thomas Roell's lobbying efforts for VRAM here,
because the deeper frame buffers get, the more important is the
"intelligence" built into VRAMS, which offer special addressing modes,
for replicating bitmap data in a preset color through all color
planes, thus offering monochrome speed for fills (though, alas, not
for copies...).

---
Thomas M. Hoberg   | Internet: tmh@first.gmd.de
1000 Berlin 41     |           tmh@cs.tu-berlin.de
Wielandstr. 4      |
Germany            | BITNET:   tmh@tub.bitnet 
+49-30-851-50-21   |