From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Thu, 31 Dec 1992 01:14:28 GMT

In <doiron.0ka3@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>Once again, you are talking about special hardware.  Even then, chunky can
>have the same optimization.  Where is this awesome planar advantage?
>Chunky is still going to take 32 writes, max.

Never said that you get an advantage in this situation. Here it is a tie.

>> Simple. The display hardware to _show_ bitplanes needs additional
>> shiftregisters and buffer which makes the hardware more expensive.

>Nope.  RAMDAC's show the display, buddy.  Not the TI chip.  And getting a
>planar display out of VRAM is a trick I'd like to see... well it could be
>done, if you want to store one plane in each VRAM, then muck about with the
>hardware, majorly.

Sure, RAMDAC's generate the analog signal. RAMDAC's however use chunky pixels
(they need all bits of a pixel to generate the analog signal for the pixel).

So if you have a plane oriented memory (which is no real problem with VRAMs
although you may get some alignment restrictions) then you have to convert
it in hardware. This needs _shiftregisters_ and _buffers_. An example for
such a hardware is the Denise and the Lisa chip (both also have a priority
logic and Denise includes the RAMDAC).

>> 32x32 pixels (well-aligned) with 8 bitplanes need 2x32x8 fetches and stores.
>> (2 words per line, 32 lines, 8 planes). In chunky you have 16x32 fetches 
>> and stores (16 wrods per line, 32 lines).

>Once again, you are considering the best, break-even case, where all your
>data is perfectly sized and aligned.  If you're going to be doing just
>that, why bother with bitmap displays at all, when a character based
>display will do just as good?

Because we do not talk about _text_ displays. You are right that we get
some inefficiencies with non-aligned data. But so with chunky pixels
if your memory isn't pixel oriented (f.e. if the memory is 16bit wide
you "waste" bandwidth on odd addresses).

Thus bitplane devices are usually same speed as chunky pixel devices. But
you can scale bitplane devices easily with the obvious performance advantages.
You can never scale chunky pixel devices.

>Do you know what data port sizes are?  Even if that was the case, worst
>case chunky could be blowing, say, 3/4 of it's time because only one pixel
>was needed.  Planar will be wasting 31/32 of it's time worst case.

Correct. But that's worst case. Average case will waste 2/4 or 16/32.

>Oh, obviously.  If you can make this magical piece of hardware, I'm sure
>Commodore has a job position open for you.  Or any other number of chip
>designers.

I could probably make that from discrete parts of fpgas but I have no
experience in doing asics or even full custom designs.

>You are doing the same transformations 8 times, once for each bitplane.
>This is not 8x the number of transformations?  You deny facts?

Again, with the example of doubling a bitmap you handle multiple pixels
at a time which exactly compensates for the number of bitplanes.

>> There is either the application of having numerical data to transform
>> and display (remember: bitplanes are just for _display_ operations).
>> There you need the chunky->bitplane conversion but which is only
>> a small fraction of the _whole_ operation.

>With this highly magical vaporhardware you keep falling back on,
>chunky->bitplane conversion should take no time at all!

I'm not talking about vaporhardware. But you are right, a special hardware
could do the chunky->bitplane conversion in no time. But I never talked
about a chunky->bitplane hardware.

>> And when operations in the bitplane domain are feasible (i.e. when the
>> numerical _value_ of a pixel is of no concern)

>huh?  How about an example to un-confuse me?

bitmap scaling can bit done on a per-plane basis.

>I don't deny that bitplanes don't use more memory than chunky pixels, it's
>just that 90% of all operations are going to be faster on chunky pixels.

I gave enough examples that they are not faster or not significantly faster.

>> Which is complete garbage. In bitplanes you write your transforms to handle
>> several pixel bits at _once_.

>Some magical software to go with that magical hardware?  Or more
>special-case optimizations?

Special-case optimizations. Right. But the "special cases" cover most graphics
operations.

>I don't.  However, you seem oblivious to the drawbacks of pixel-based
>operations in a planar display.  Even blit operations will almost always
>take more time on planar displays.

they take more time in the worst case (because a single memory word stores
several pixels). In the average a blit is done in equal speed if the amount
of data is equal.

>> As I said, drawing a single pixel wide line wins on chunky.

>Wow... agreement.. (even if slightly incorrect)
>However, drawing a n-pixel wide line also wins on chunky (where n>0 :)

Depends.

>> Now render a 64 color image to your 256 color display :) 

>See the above mentioned case of blits.  The best you can hope for is a tie,
>since with planar you have to clear the top two bitplanes anyways.

Except if you can guarantee that they are already cleared.

>> Or render
>> a black/white text in your window on a 256 color desktop.

>See above.  You still have to clear the other bitplanes.  And some chunky
>hardware supports color expansion, too, where you take a single-bit image
>and can expand all 0's to one color and 1's to another.  Of course, a
>similar thing could be done for planar, but you still have the
>masking/shifting/bandwidth on unaffected pixels problems.  (Say it 3 times
>real fast.)

The special hardware cannot magically expand the pixels since the bitmap
in the frame buffer (VRAM) needs all pixels to be defined. In chunky you
cannot write single bits into a pixel and have any speed advantage.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
Xref: sparky comp.sys.amiga.programmer:17790 comp.sys.amiga.misc:19042