From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Date: 11 Jan 93 14:53:06 GMT
Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Organization: Commodore Germany

I know I'm coming a little late in this debate, but only some few remarks:

In article <doiron.0kil@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>In article <1993Jan1.141207.20262@mpifr-bonn.mpg.de> mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst) writes:
>> In <doiron.0kd5@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>> >> 
>> >> So if you have a plane oriented memory (which is no real problem with VRAMs
>> >> although you may get some alignment restrictions) 

Yes, severe restrictions, but then it should be possible.

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

Yes, sure. Or put it more generally: Every bitplane has to start at the same
offset in every VRAM chip. That's an alignment of the size of one VRAM chip
as compared to 16-bit alignment in <= ECS or greater portions in AA. But not
at all impossible IMHO.

>> >then mess further with your RAMDAC feeding setup.  

Why that??? Every VRAM delivers one bit for the current pixel, *exactly*
the same situation as in a chunky environment. What additional effort
would be necessary?

>> >Using VRAMS like DRAMS will result in a loss of
>> >all the performance gains VRAMS were supposed to give you in the first
>> >place.

Don't get that.

>As I said, you lose all the performance gains VRAMS were supposed to give
>you in the first place, since you can't use the serial registers for video
>fetch in planar setups.

Of course you can, if you obey the mentioned alignment rules. Not impossible
at all in my eyes.

>No.  It is not.  You are doing N time the amount of work in planar, where N
>is the number of planes.

This is overgeneralization. Whenever you have data that also have some
width > 1 pixel, then you can cut down the number of fetches and stores
with appropriate (I'm not saying "tricky" or "genius-like") coding.

>I'm not going to argue with you about depth scaling.  Given the same depth,
>chunky will be faster for all of the above operations, with exception of a
>few break-even cases.  Sometimes it will even be faster on chunky *even
>with a reduced scale for planar*, since chunky doesn't need 'bit
>thrashing'.

All this becomes immediately invalid and turns into a pro argument for
planes when your bits per pixel are not multitudes of 8!

>:)  Look, if you want a 128-color display, I won't forbid you from using a
>planar architecture.  However, drawing a line will be far faster on a
>256-color chunky than a 128-color planar display.  

Yes, but 8 bits per pixel is not the be-all-end-all of all worlds! There
are many situations where you can very nicely do with fewer bits, say
5 or 6, and then you are going to waste memory *and* processor cycles
with a chunky architecture. I think it's *not* realistic to caculate
always with an 8-bit case only. (I say "realistic", not "unfair", because
we want to deal with what comes across us in our dayly needs.)

Yes, for n*8 bits/pixel, chunky is in most cases the best option. (I still
believe there also situations where planar can be better also here.)
If you have some odd number of bits, then I guess the planar structure
has more advantages.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
Wer's nicht kann, soll's bleiben klopfen oder Steine lassen!