home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2689 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.7 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Sat, 03 Feb 96 17:35:15 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Amiga doesn`t need Planar!
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4biy@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 02 Feb 96 Michael Van Elst wrote to All:
  14.  
  15.  >> Yes, but a planar system needs more memory accesses on average because of
  16.  >> more severe alignment restrictions than Chunky,
  17.  
  18.  MVE> or less because of different needs of bits per pixel.
  19.  
  20. Not really important as it is 8-bit, 16-bit, 24-bit or 32-bit in today's world,
  21. well except Amiga that is.
  22.  
  23. Thank god C= didn't invent 'planar' sound hardware...
  24.  
  25.  >> In other words
  26.  >> Planar can't take advantage of wider memory-busses as good as Chunky can.
  27.  
  28.  MVE> That's garbage. With a wider memory bus you increase alignment needs
  29.  MVE> for both systems. And with your CPU-only system you can't use much
  30.  
  31. True, but with a 8-bit bus the Chunky alignment needs are non-existant, while
  32. planar already has 8-pixel alignment with that bus.  It gets worse for planar
  33. far faster as planar has a headstart in this.
  34.  
  35.  MVE> beyond 32bit. Of course that's not a real chunky problem.
  36.  
  37. And I never said the system would be CPU only, would be quite ridiculous to do
  38. that.  It is just an advantage of Chunky that the CPU can handle the display
  39. very well too.
  40.  
  41.  MVE> On the other hand it is pretty simple to use the wider bus to access
  42.  MVE> completely different regions of the RAM. You can scale the planar
  43.  MVE> hardware with the bus width a operate on multiple planes in parallel.
  44.  
  45. Hmmm...  so what you're saying is that if you had a 64-bit memory bus, and
  46. 'somehow' managed to rearrange memory in such a way that the same bytes of
  47. every 8 bitplanes are located next to each other you could modify them in just
  48. one access?  Ie, if you plot a pixel in 8-bit you could do it in one access? 
  49. That would be nice, but if you do that you lose the main advantage of planar,
  50. fast manipulation of single bitplanes.  It would effectively turn your planar
  51. hardware into Chunky hardware, with almost the same advantages and
  52. disadvantages, except that to the CPU it LOOKS like Planar.
  53.  
  54. Question is why would you ever want to do that?  Not only does it require much
  55. wider memory busses to get good speed, you also lose the primary advantage of
  56. bitplanes (accessing them one plane at the time).  On top of that you make it
  57. hard for the CPU to use this display as it is still planar.  It doesn't make
  58. sense to do this unless you were doing it to be compatible or something with
  59. hardware banging programs.
  60.  
  61. When I come to think of it this isn't possible at all unless you got some
  62. adaptive memory hardware or something.  I mean, what would happen if you
  63. displayed 7 bitplanes this way? Would you have 1 byte unused after every 7 used
  64. bytes?  What if I opened a 2nd screen?  Could I use that 'extra' byte for a
  65. bitplane of a different screen?  This would also kill Planar's advantage of
  66. having multiple bitplane pointers as they would need to be at specific
  67. locations in memory (kinda like a Interleaved bitmap).  I don't think this is a
  68. reasonable possibility at all, in terms of cost and effort. You might as well
  69. go Chunky right away and save yourself the mess.
  70.  
  71.  >> As you can see the best planar gets is equal speed, but only under very,
  72.  >> VERY specific circumstances.
  73.  
  74.  MVE> Why don't you compare wider rectangles ? The more data you have the
  75.  
  76. We were talking about thick lines (which I changed to rectangles to make things
  77. easier), I couldn't make them any wider for just lines.
  78.  
  79.  MVE> smaller are the differences. Why don't you compare the cases where not
  80.  MVE> 8 bit per pixel are needed ?
  81.  
  82. Because those are irrelevant, 8 bits per pixel is the standard, if planar can't
  83. handle that fast than planar simply sucks.
  84.  
  85.  >> Chunky wins hands down in the last case however.  So as I said, the line
  86.  >> would have to be very thick to get good speeds on planar. 
  87.  
  88.  MVE> Don't forget the overhead for the CPU to determine BYTE and WORD
  89.  MVE> accesses, even more when you don't draw straight vertical lines.
  90.  
  91. Who's talking about the CPU?  It would be kinda unfair to compare CPU Chunky vs
  92. Hardware Planar (although even then Planar doesn't look too good).  The fact
  93. that the CPU can 'help' with Chunky is just a bonus, there still is Chunky
  94. hardware of course.
  95.  
  96.  >> Drawing a horizontal line would of course be better on planar (although
  97.  >> still equally fast in the best case), but as in that case the speed is
  98.  >> about the same it is not really interesting.
  99.  
  100.  MVE> Sure. Just the worst cases are interesting for you.
  101.  
  102. Actually only near horizontal lines are 'good cases'.  As soon as the line is
  103. more than 45 degrees vertical the 'worst case' can be applied.
  104.  
  105.  >> The point is that if it takes more memory accesses to do a specific
  106.  >> action than no matter what hardware you throw at it the number of memory
  107.  >> accesses will remain higher.
  108.  
  109.  MVE> No. Try a 12bit/pixel display and don't forget to count all the
  110.  MVE> overhead involved in the CPU to handle packed data.
  111.  
  112. A fast CPU would laugh at this 'overhead' as memory accesses are so slow it can
  113. easily handle the extra calculations needed 'in between' memory accesses (like
  114. 040 C2P).  And there is still the Chunky hardware which can do it for you...
  115.  
  116. Anyway, I explained why I think wider memory busses wouldn't work as good with
  117. Planar in an other message to you.
  118.  
  119. Grtz John
  120.  
  121. -----------------------------------------------------------------------
  122.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  123. -----------------------------------------------------------------------
  124. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  125.