NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/windows/x/i386unix/83

Text File | 1992-12-21 | 6.1 KB | 132 lines

Newsgroups: comp.windows.x.i386unix
Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!cbnewsk!cbnewsj!dwex
From: [e-mail] (david.e.wexelblat)
Subject: Re: 32K or 16M colours?
Organization: AT&T
Date: Mon, 21 Dec 1992 03:27:15 GMT
Message-ID: <[e-mail]>
References: <linda.724803368@minnie> <[e-mail]> <[e-mail]>
Lines: 121

In article <[e-mail]> [e-mail] (Thomas Hoberg) writes:
> In article <[e-mail]> [e-mail] (david.e.wexelblat) writes:
>    In article <linda.724803368@minnie> [e-mail] (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.
>

The X11R5 cfb is completely new - there is little to no correlation to
the X11R4 cfb.  I have it on good authority that it is known to not work
at depths other than 8 bits.

>        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.
>

No.  Banking has very little to do with the assembler in XFree86.  All of
the BitBlt and line drawing code have been done in assembler (either from
SpeedUp or from fX386), and move 8-bit pixels around.  This is what gives
the performance improvements over the stock cfb.banked, for the most part.

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

True, but banking is actually fairly simple.  This is the reason that I know
that X11R5's cfb only works at 8 bits.  Members of the X Consortium have
cfb versions for 8-bit, 16-bit, and 24/32-bit frame buffers.  When, or if,
this will be made public, I have no idea, but certainly not before X11R6.

>        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!).
>
Take a look at how the 24-bit SVGA's are implemented.  Packed 3-byte pixels.
It's going to make working on them rediculous.

>        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).

Wrong.  Take a look at the hardware interface of the Sierra RAMDAC.  It's
got 8 bits between the frame buffer memory and the RAMDAC.  It takes two
memory cycles to load a 15-bit HiColor pixel.  I'm pretty sure that the
24-bit RAMDACs also have an 8-bit interface, hence requiring 3 cycles
to get a single pixel.

>
> >   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).
>

Sorry, but you're wrong.  You could port X11R4 that way, but not R5.  You
have to go fix the bugs in cfb.  The banking code in cfb.banked will work
at 16-bits as well as 8-bits.  The assembler would need work, but not
the C code.

> >   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...
>

They do.

> 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...).

Actually getting rid of the stupid pixel-packing would do more than VRAM,
at this point.  Of course, one would think that anyone would go and buy
a VRAM based board.  But you'd be surprised how many people want to
use XFree86 on a DRAM-based Trident board (~$60 US).  Ichh!

>
> ---
> Thomas M. Hoberg   | Internet: [e-mail]
> 1000 Berlin 41     |           [e-mail]
> Wielandstr. 4      |
> Germany            | BITNET:   [e-mail]
> [phone]   |


--
David Wexelblat <[e-mail]>  [phone]
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