home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3522 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.9 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: TMapping again!
  5. Date: 21 Feb 1996 14:35:35 GMT
  6. Organization: Teleport - Portland's Public Access (503) 220-1016
  7. Message-ID: <4gfajn$7bd@maureen.teleport.com>
  8. References: <38232371@kone.fipnet.fi> <4fntd3$g56@sunsystem5.informatik.tu-muenchen.de> <38232442@kone.fipnet.fi> <4fvnjb$gdm@oreig.uji.es> <4g147q$sit@maureen.teleport.com> <4ga6lr$rp8@brachio.zrz.TU-Berlin.DE> <4gc5ur$brr@maureen.teleport.com> <4gcq6s$b1h@brachio.zrz.TU-Berlin.DE>
  9. NNTP-Posting-Host: linda.teleport.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Philipp Boerker (rawneiha@hydra.zrz.TU-Berlin.DE) wrote:
  13. : >: > I would unroll the innerloop, you probably can save hundreds of dbra
  14.  
  15. : >: If you have an object with let's say 5000 polys umrolling will mean
  16. : >: a big overhead because of the treatment of "pixels modulo unrolling".
  17. : >: You may never enter that unrolled loop!
  18.  
  19. : > What do you mean by "pixel modulo unrolling"? Never enter the loop?!?!
  20. : > then you dont draw any pixels so its VERY fast :)
  21.  
  22. : if you do a innerloop mapping 16 pixels at once you need to map   
  23. : number_of_pixels_you_have_to_map % 16 independently. For instants
  24. : 45 pixels to map would result in 2 executions of your 16 pixel loop
  25. : plus 13 executions of 1-pixel loop. number_pixel < 16 will not make use
  26. : of your loop at all!
  27.  
  28.  Then see the folowing... its not using a unrolling methode for 
  29.  alligned 'copy' like for flat shading inner loop unrolling.
  30.  
  31. : > Its true that there is some overhead, But here is an example:
  32.  
  33. : >    ...
  34. : >    moveq    #%1111,d3    ;2
  35. : >    and.w    d2,d3        ;2
  36. : >    neg.w    d3        ;2
  37. : >    lsr.w    #4,d2        ;4
  38. : >    jmp    (.z,pc,d3.w*8)    ;10 = 20 per scanline
  39. : > ..    REPEAT    16
  40. :   ^^ what a great label :)
  41.  
  42.  It is! I love it, one reason why basm support it ;)
  43.  
  44. Setup:
  45. ..     move.l    d0,(a1)+
  46.     dbra    d1,..
  47. ..    move.l    d2,(a1)+
  48.     dbra    d3,..
  49.     rts
  50.  
  51.  Now, isn't this nice :)
  52.  
  53. : >    move.b    (a0,d0.w),(a1)
  54. : >    addx.l    d1,d0
  55. : >    adda.l    a2,a1
  56. : >    ENDR
  57. : >.z    dbra    d2,..        ;6 per pixel
  58. : >    ...
  59.  
  60.  BTW, on a 030, you might want to freze the cache here. (if the function
  61.  is called over and over... so the cache dont load data that will be
  62.  executed once, then load the loop, then load data that will be execute
  63.  once.. etc..)
  64.  
  65. : Hm, this is a wall mapping loop, I thought we were talking about
  66. : polygon mapping, where you have lots of polys smaller than 16 pixels width
  67. : if you do *many* polys (therefor the number 5000).
  68.  
  69.  Ok, replace the innerloop by your favority mapping code. doens't matter
  70.  I just wnated to ilustrate the methode of unrolling.
  71.  
  72. : > now if this 'polygon' is more then 4 pixel height its worth it... well,
  73. : > if its a few pixel width too :) 
  74.  
  75. : ??? to use this loop you will have to have more than 16 pixels!
  76. : The treatment of number_pixels mod 16 will add a big overhead for small
  77. : polys, like I said above.
  78.  
  79.  Nope from ZERO to 65536.... and it unroll any number, upto 16.
  80.  if the width is 0, no pixel will be mapped, the dbra wont branch,
  81.  if the width its 3, it will map 3 pixel, the dbra wont branch...
  82.  the bra will branch only if > 16 pixels are needed to be mapped.
  83.  Also all the unroled loop wont be cached... only the number of pixel
  84.  you accesed... 
  85.  
  86. : > If the poly where to be ~4x4 pixel I would think rendering then using
  87. : > the average color of the texture (precalculated of course) and use a
  88. : > flat shading function (using also the average of the light value at the
  89. : > triangle vertices
  90.  
  91. : You will hardly stuff all that into your 256 B cache. According to my
  92. : experience it is better to have an ordinary loop and outer loops in cache
  93. : than spending the cache for case-optimized loops.
  94.  
  95.  I was just talking about switching rendering methode for tiny little 
  96.  things... You dont have too. But if I know a poly is 2 pixel height, why 
  97.  bother calculating texture steping and lighting etc. when its just a spec.
  98.  on the screen. Or you can alway have a level of detail for you object 
  99.  acording to the z value, an even faster methode.
  100.  
  101.  Stephan
  102.