NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/amiga/programm/18011

Internet Message Format | 1992-12-31 | 10.0 KB

Path: sparky!uunet!spool.mu.edu!olivea!bunker!nuconvex!starpt!doiron
From: [e-mail] (Glenn Doiron)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Message-ID: <[e-mail]>
Date: 1 Jan 93 00:58:35 GMT
References: <[e-mail]> <[e-mail]>           <[e-mail]>
Organization: 68K Software Development
Lines: 209
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith

In article <[e-mail]> [e-mail] (Michael van Elst) writes:
> In <[e-mail]> [e-mail] (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.

It's a tie if you're using special hardware, with a 32-point wide vertical
line which happens to lie entirely within the span of a single longword.
Wow, it was a tie.  Now, how about some more realistic examples?

> >> 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 what, planar systems still need all bits of a pixel to generate the
pixel, too.  Your point?

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

... which use DRAM's, not VRAMS.  No amount of 'alignment restrictions' is
going to cut it for VRAM planar, unless, as I said, you do funky
address/data schemes and put one plane in each VRAM, then mess further with
your RAMDAC feeding setup.  Using VRAMS like DRAMS will result in a loss of
all the performance gains VRAMS were supposed to give you in the first
place.

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

"Scale"??  Remember, scaling is at least (in this example) 8x slower in
planar than chunky.

> >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.  Pardon me, I should have realized that the average cases
waste exactly 1/2 the time.  Let's put it this way:  Chunky will be wasting
2*8/32= 1/2 a cycle, while planar will be wasting 16*8/32=4 cycles.  Each
time this happens, which will likely be as many times as there are
horizontal lines in the image you are blitting.

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

Why hasn't someone done it already?  Musn't be very cost-effective.

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

Rubbish.  Show me a piece of code that can do that.  More special-case
optimizations? (sigh...)

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

But you're saying chunky->bitplane conversion is a small fraction of the
whole operation.  It's not.  That ridiculous amount of masking/shifting
might even take longer than the matrix multiplications.  For instance, on a
68000, each shift takes *2* additional clock cycles! (yuck!)

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

As I said, this is 8x the amount of work chunky has to do.  (You're doing
it a bit at a time instead of a byte at a time.)

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

You gave enough examples where special vaporware or special-case
optimizations might make them break even with chunky's results without
any optimization whatsoever.

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

Oh, yeah.  Right.  Most graphics operations consist of 32-bit wide
vertical lines, conincidentally placed on a long-word boundary.  Most
operations consist of exactly doubling the size of horizontal/vertical
dimension.  Most operations consist of blitting data that's perfectly sized
and aligned to a perfectly aligned place on the screen.  Yep, that's all of
them.  I can't think of any other graphics operations you can do.

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

Suppose you have hundreds, thousands of blits?  In general the speed of
blits isn't that critical for most productivity software, but
graphically-oriented software will benefit greatly from chunky
architecture.

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

On WHAT???  Where you live?  If you wear underoos?  WHAT???!?? <foaming at
the mouth>

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

Oh, I see.  More special case optimizations.  So you SAY it's a 256-color
display-  BUT you guarantee the top 2 bitplanes are already clear?

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

Urrm, maybe I didn't explain that correctly.  Some chips will take a
1-pixel chunky image (same as 1-plane planar image), and write out 8-bit
data of value X for a 1 and Y for a 0.  So your character sets in chunky
actually only take up 1/8th as much, and foreground/background colors can
be set before you start the blit.  It's a function of the processor being
used, not chunky pixels.

> Regards,
> --
> Michael van Elst
> UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
> Internet: [e-mail]
>                                 "A potential Snark may lurk in every tree."

Glenn Doiron
--
Amiga UUCP+
Origin:  uunet.uu.net!starpt.UUCP!doiron (Organization:68K Software Development)
         BIX: gdoiron
** Not enough memory to perform requested operation.  Add 4 megs and retry.