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

Text File | 1992-12-30 | 6.7 KB | 144 lines

Newsgroups: comp.sys.amiga.programmer
Path: sparky!uunet!mcsun!Germany.EU.net!mpifr-bonn.mpg.de!speckled.mpifr-bonn.mpg.de!mlelstv
From: [e-mail] (Michael van Elst)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: speckled
Organization: Max-Planck-Institut f"ur Radioastronomie
References: <[e-mail]> <[e-mail]>         <[e-mail]> <[e-mail]>
Date: Wed, 30 Dec 1992 11:57:59 GMT
Lines: 131

In <[e-mail]> [e-mail] (Glenn Doiron) writes:
>> In <[e-mail]> [e-mail] (Glenn Doiron) writes:
>> > 32-point line,
>> > 2 pixels thick:  512 reads 512 writes       64 writes
>> > (Why are bitplanes better for this?  Seems like an additional 960 memory
>> >  accesses to me.)
>>
>> It would be still 256 reads 256 writes unless the line spans over a word
>> boundary. More, shallow lines will need less reads and writes.

>the same word boundary", you are talking special hardware.  BTW you are
>still confusing the issue;  you are comparing a 32-bit cpu access planar system
>to an 8-bit cpu access chunky system.

A 32 point line with 8 bitplanes needs 32 * 8 reads and writes _worst_case_.
A two pixel wide line will need the same if all pixels are in one memory word
(bytes, words,longwords whatever).

Where do I refer to a 32bit CPU ??? Where do I even _talk_ about a CPU ?

>> However, your line drawing routine will need cycles itself. So unless
>> your rendering is done in hardware the difference gets smaller.

>TMS340x0's have Bresenham's line-drawing algorithm embedded in hardware.
>They also support chunky-pixel displays.  They don't support planar
>displays.  I wonder why.  Oops, I strayed from the topic too, sorry...

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

>> > 32x32 blit:      1536 reads 512 writes      1024 reads, up to 1024 writes
>> >         or up to 2304 reads 768 writes
>> > (second case if either source or dest. non-aligned)
>> > (including transparency/masking)
>>
>> 32x32 blit is 512 reads/writes. more for non-aligned objects. chunky
>> needs 512 reads/writes and a little more for non-aligned objects.
>(I was using the Amiga's blitter as a reference here)
>> (Both do word accesses).

>Here you go again.  First you're talking about 16-bit accesses, now 32-bit
>accesses.  Please compare planar 32-bit vs. chunky 32-bit, not planar
>32-bit vs. chunky 8-bit, as you seem oblivious to the differences.  In any
>case, the planar system will almost always lose for two reasons:

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

I didn't ever say anything about 32bit accesses not do I refer to 8bit
chunky accesses. Both used 16bit transfers.

>  1  Chunky doesn't need to do a write if this is a transparent pixel.
>  2  Chunky doesn't lose time if the data is not perfectly/wholly aligned.

Chunky _needs_ to write transparent pixels and _needs_ to care about
alignment _if_ you do memory access larger than a pixel. You either
have to use _8bit_ accesses or use the complete buswidth with the
same constraints as in bitplanes.

>Here's the point:  <<EACH SYSTEM HAS TO MOVE THE SAME AMOUNT OF DATA>>,
>but <<PLANAR MUST AFFECT ANY ADJACENT PIXELS IN THE BOUNDARY WHILE CHUNKY
>DOES NOT>>.  (once again ignoring the shifting/masking aspects which you
>seem to patently ignore as if they were of no consequence at all)

Shifting/Masking is a no-time operation in hardware. If you talk about
general purpose CPUs then please account for instruction fetches as well.

>So how is doing 8x the number of mathematical transformations possibly
>going to be faster, not to mention the masking/bit shifting?  And 'table
>look-up' isn't anywheres close to general purpose.  Once again, you're
>talking about a special-case optimisation, one that can also be done with
>chunky pixels just as well.

You were refering to the _special_ case of expanding a bitmap by the factor
of 2. I gave an example.

You also do not use 8x the number of mathematical transforms.

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.

And when operations in the bitplane domain are feasible (i.e. when the
numerical _value_ of a pixel is of no concern) then you can operate
on individual bitplanes and get _multiple_ pixels per memory fetch
which _exactly_ outweighs the factor of havint _multiple_ bitplanes.
As I said, in the end the memory bandwidth determines the speed of
your operation and bitplanes do not use more memory than chunky pixels.

>Planars's losses go up directly as your blit gets larger.  The overhead for
>the mathematical xforms is the same, but with what you're saying, planar
>will take N times longer, where N is the number of bitplanes.

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

>Bitplanes will be faster for 12.5% whenever you have data that is perfectly
>aligned, perfectly sized, and special hardware to do those shifting and
>masking operations which you seemingly dismiss as taking no cpu-time
>whatsoever {evil grin}.  Unfortunately, this is seldom the case, and even
>in 7-bit color chunky will win in most of the operations being discussed.

Why do you  deny the facts ?

>Now, if you are talking about copying entire screens of data, like ANIM,
>yes, planar can take that 12.5% speedup.  But most graphic operations will
>do much better on planar than chunky.

Correct :) Most graphic operations do much better on planar than chunky :)

>Tell you what.  Code a routine that
>will plot a line from (X1,Y1) to (X2,Y2) in color C on an 8-bitplane 32-bit
>access system.  Now do the same thing for an 8-bit chunky 32-bit access
>system.  Look at the code.  Tell me which one is doing (a *hell of a lot*)
>more calculations.   Which one accessing video memory (a *hell of a lot*)
>more often.  Now, tell me which one is going to run faster on *any*
>machine?

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

Now render a 64 color image to your 256 color display :) Or render
a black/white text in your window on a 256 color desktop.

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