home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18538 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  4.0 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!mpifr-bonn.mpg.de!uniol!caty!cbmger!peterk
  2. From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
  5. Message-ID: <10408@cbmger.de.so.commodore.com>
  6. Date: 11 Jan 93 14:53:06 GMT
  7. References: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu> <1993Jan1.141207.20262@mpifr-bonn.mpg.de> <doiron.0kil@starpt.UUCP>
  8. Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
  9. Organization: Commodore Germany
  10. Lines: 75
  11.  
  12. I know I'm coming a little late in this debate, but only some few remarks:
  13.  
  14. In article <doiron.0kil@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
  15. >In article <1993Jan1.141207.20262@mpifr-bonn.mpg.de> mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst) writes:
  16. >> In <doiron.0kd5@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
  17. >> >> 
  18. >> >> So if you have a plane oriented memory (which is no real problem with VRAMs
  19. >> >> although you may get some alignment restrictions) 
  20.  
  21. Yes, severe restrictions, but then it should be possible.
  22.  
  23. >> >... which use DRAM's, not VRAMS.  No amount of 'alignment restrictions' is
  24. >> >going to cut it for VRAM planar, unless, as I said, you do funky
  25. >> >address/data schemes and put one plane in each VRAM, 
  26.  
  27. Yes, sure. Or put it more generally: Every bitplane has to start at the same
  28. offset in every VRAM chip. That's an alignment of the size of one VRAM chip
  29. as compared to 16-bit alignment in <= ECS or greater portions in AA. But not
  30. at all impossible IMHO.
  31.  
  32. >> >then mess further with your RAMDAC feeding setup.  
  33.  
  34. Why that??? Every VRAM delivers one bit for the current pixel, *exactly*
  35. the same situation as in a chunky environment. What additional effort
  36. would be necessary?
  37.  
  38. >> >Using VRAMS like DRAMS will result in a loss of
  39. >> >all the performance gains VRAMS were supposed to give you in the first
  40. >> >place.
  41.  
  42. Don't get that.
  43.  
  44. >As I said, you lose all the performance gains VRAMS were supposed to give
  45. >you in the first place, since you can't use the serial registers for video
  46. >fetch in planar setups.
  47.  
  48. Of course you can, if you obey the mentioned alignment rules. Not impossible
  49. at all in my eyes.
  50.  
  51. >No.  It is not.  You are doing N time the amount of work in planar, where N
  52. >is the number of planes.
  53.  
  54. This is overgeneralization. Whenever you have data that also have some
  55. width > 1 pixel, then you can cut down the number of fetches and stores
  56. with appropriate (I'm not saying "tricky" or "genius-like") coding.
  57.  
  58. >I'm not going to argue with you about depth scaling.  Given the same depth,
  59. >chunky will be faster for all of the above operations, with exception of a
  60. >few break-even cases.  Sometimes it will even be faster on chunky *even
  61. >with a reduced scale for planar*, since chunky doesn't need 'bit
  62. >thrashing'.
  63.  
  64. All this becomes immediately invalid and turns into a pro argument for
  65. planes when your bits per pixel are not multitudes of 8!
  66.  
  67. >:)  Look, if you want a 128-color display, I won't forbid you from using a
  68. >planar architecture.  However, drawing a line will be far faster on a
  69. >256-color chunky than a 128-color planar display.  
  70.  
  71. Yes, but 8 bits per pixel is not the be-all-end-all of all worlds! There
  72. are many situations where you can very nicely do with fewer bits, say
  73. 5 or 6, and then you are going to waste memory *and* processor cycles
  74. with a chunky architecture. I think it's *not* realistic to caculate
  75. always with an 8-bit case only. (I say "realistic", not "unfair", because
  76. we want to deal with what comes across us in our dayly needs.)
  77.  
  78. Yes, for n*8 bits/pixel, chunky is in most cases the best option. (I still
  79. believe there also situations where planar can be better also here.)
  80. If you have some odd number of bits, then I guess the planar structure
  81. has more advantages.
  82.  
  83. -- 
  84. Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
  85. Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
  86. Wer's nicht kann, soll's bleiben klopfen oder Steine lassen!
  87.