home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 17964 < prev    next >
Encoding:
Text File  |  1992-12-30  |  6.5 KB  |  149 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!mcsun!Germany.EU.net!mpifr-bonn.mpg.de!specklec.mpifr-bonn.mpg.de!mlelstv
  3. From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
  4. Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
  5. Message-ID: <1992Dec31.011428.2926@mpifr-bonn.mpg.de>
  6. Sender: news@mpifr-bonn.mpg.de
  7. Nntp-Posting-Host: specklec
  8. Organization: Max-Planck-Institut f"ur Radioastronomie
  9. References: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu>          <1992Dec30.115759.22097@mpifr-bonn.mpg.de> <doiron.0ka3@starpt.UUCP>
  10. Date: Thu, 31 Dec 1992 01:14:28 GMT
  11. Lines: 136
  12.  
  13. In <doiron.0ka3@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
  14. >Once again, you are talking about special hardware.  Even then, chunky can
  15. >have the same optimization.  Where is this awesome planar advantage?
  16. >Chunky is still going to take 32 writes, max.
  17.  
  18. Never said that you get an advantage in this situation. Here it is a tie.
  19.  
  20. >> Simple. The display hardware to _show_ bitplanes needs additional
  21. >> shiftregisters and buffer which makes the hardware more expensive.
  22.  
  23. >Nope.  RAMDAC's show the display, buddy.  Not the TI chip.  And getting a
  24. >planar display out of VRAM is a trick I'd like to see... well it could be
  25. >done, if you want to store one plane in each VRAM, then muck about with the
  26. >hardware, majorly.
  27.  
  28. Sure, RAMDAC's generate the analog signal. RAMDAC's however use chunky pixels
  29. (they need all bits of a pixel to generate the analog signal for the pixel).
  30.  
  31. So if you have a plane oriented memory (which is no real problem with VRAMs
  32. although you may get some alignment restrictions) then you have to convert
  33. it in hardware. This needs _shiftregisters_ and _buffers_. An example for
  34. such a hardware is the Denise and the Lisa chip (both also have a priority
  35. logic and Denise includes the RAMDAC).
  36.  
  37. >> 32x32 pixels (well-aligned) with 8 bitplanes need 2x32x8 fetches and stores.
  38. >> (2 words per line, 32 lines, 8 planes). In chunky you have 16x32 fetches 
  39. >> and stores (16 wrods per line, 32 lines).
  40.  
  41. >Once again, you are considering the best, break-even case, where all your
  42. >data is perfectly sized and aligned.  If you're going to be doing just
  43. >that, why bother with bitmap displays at all, when a character based
  44. >display will do just as good?
  45.  
  46. Because we do not talk about _text_ displays. You are right that we get
  47. some inefficiencies with non-aligned data. But so with chunky pixels
  48. if your memory isn't pixel oriented (f.e. if the memory is 16bit wide
  49. you "waste" bandwidth on odd addresses).
  50.  
  51. Thus bitplane devices are usually same speed as chunky pixel devices. But
  52. you can scale bitplane devices easily with the obvious performance advantages.
  53. You can never scale chunky pixel devices.
  54.  
  55. >Do you know what data port sizes are?  Even if that was the case, worst
  56. >case chunky could be blowing, say, 3/4 of it's time because only one pixel
  57. >was needed.  Planar will be wasting 31/32 of it's time worst case.
  58.  
  59. Correct. But that's worst case. Average case will waste 2/4 or 16/32.
  60.  
  61. >Oh, obviously.  If you can make this magical piece of hardware, I'm sure
  62. >Commodore has a job position open for you.  Or any other number of chip
  63. >designers.
  64.  
  65. I could probably make that from discrete parts of fpgas but I have no
  66. experience in doing asics or even full custom designs.
  67.  
  68. >You are doing the same transformations 8 times, once for each bitplane.
  69. >This is not 8x the number of transformations?  You deny facts?
  70.  
  71. Again, with the example of doubling a bitmap you handle multiple pixels
  72. at a time which exactly compensates for the number of bitplanes.
  73.  
  74. >> There is either the application of having numerical data to transform
  75. >> and display (remember: bitplanes are just for _display_ operations).
  76. >> There you need the chunky->bitplane conversion but which is only
  77. >> a small fraction of the _whole_ operation.
  78.  
  79. >With this highly magical vaporhardware you keep falling back on,
  80. >chunky->bitplane conversion should take no time at all!
  81.  
  82. I'm not talking about vaporhardware. But you are right, a special hardware
  83. could do the chunky->bitplane conversion in no time. But I never talked
  84. about a chunky->bitplane hardware.
  85.  
  86. >> And when operations in the bitplane domain are feasible (i.e. when the
  87. >> numerical _value_ of a pixel is of no concern)
  88.  
  89. >huh?  How about an example to un-confuse me?
  90.  
  91. bitmap scaling can bit done on a per-plane basis.
  92.  
  93. >I don't deny that bitplanes don't use more memory than chunky pixels, it's
  94. >just that 90% of all operations are going to be faster on chunky pixels.
  95.  
  96. I gave enough examples that they are not faster or not significantly faster.
  97.  
  98. >> Which is complete garbage. In bitplanes you write your transforms to handle
  99. >> several pixel bits at _once_.
  100.  
  101. >Some magical software to go with that magical hardware?  Or more
  102. >special-case optimizations?
  103.  
  104. Special-case optimizations. Right. But the "special cases" cover most graphics
  105. operations.
  106.  
  107. >I don't.  However, you seem oblivious to the drawbacks of pixel-based
  108. >operations in a planar display.  Even blit operations will almost always
  109. >take more time on planar displays.
  110.  
  111. they take more time in the worst case (because a single memory word stores
  112. several pixels). In the average a blit is done in equal speed if the amount
  113. of data is equal.
  114.  
  115. >> As I said, drawing a single pixel wide line wins on chunky.
  116.  
  117. >Wow... agreement.. (even if slightly incorrect)
  118. >However, drawing a n-pixel wide line also wins on chunky (where n>0 :)
  119.  
  120. Depends.
  121.  
  122. >> Now render a 64 color image to your 256 color display :) 
  123.  
  124. >See the above mentioned case of blits.  The best you can hope for is a tie,
  125. >since with planar you have to clear the top two bitplanes anyways.
  126.  
  127. Except if you can guarantee that they are already cleared.
  128.  
  129. >> Or render
  130. >> a black/white text in your window on a 256 color desktop.
  131.  
  132. >See above.  You still have to clear the other bitplanes.  And some chunky
  133. >hardware supports color expansion, too, where you take a single-bit image
  134. >and can expand all 0's to one color and 1's to another.  Of course, a
  135. >similar thing could be done for planar, but you still have the
  136. >masking/shifting/bandwidth on unaffected pixels problems.  (Say it 3 times
  137. >real fast.)
  138.  
  139. The special hardware cannot magically expand the pixels since the bitmap
  140. in the frame buffer (VRAM) needs all pixels to be defined. In chunky you
  141. cannot write single bits into a pixel and have any speed advantage.
  142.  
  143. Regards,
  144. -- 
  145. Michael van Elst
  146. UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
  147. Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
  148.                                 "A potential Snark may lurk in every tree."
  149.