home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 5200 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.0 KB
  1. Path: informatik.tu-muenchen.de!fischerj
  2. From: fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: doubling pixels horizontally
  5. Date: 11 Mar 1996 01:47:41 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4i00nt$r3g@sunsystem5.informatik.tu-muenchen.de>
  9. References: <4f4ibc$gl9@news.cs.tu-berlin.de> <591.6610T1165T2102@login.eunet.no><1045.6611T753T2256@vip.cybercity.dk><4faoe1$47@sunsystem5.informatik.tu-muenchen.de><2991.6612T1034T625@vip.cybercity.dk><576.6613T1070T1730@login.eunet.no><1257.6614T57T922@vip.cybercity.dk> <5257.6639T1152T2935@ifi.uio.no>
  10. NNTP-Posting-Host: hphalle9.informatik.tu-muenchen.de
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Ludvig Pedersen (ludvigp@ifi.uio.no) wrote:
  14. : >in C code. And as asm needs more instructions than C, it needs the
  15. : >2 dimensional format even more if you don't wanna lose overwiev. baeh!
  16. : >:)
  17.  
  18. : Asm was never design for it, and I don't think it looks good either.
  19. I redesigned it :D blah.
  20.  
  21. : >|> >a myth ?
  22. : >|> I think so. But please show me the copy-loop and I'll test it.
  23. : >could you please try movem.l (fast)+,d0-d7 and then 8 times move.l dn,(chip)+
  24. : >?
  25.  
  26. : I did tried a LOT of different loops and here is a small collection of
  27. : the top 5 loops I tried. Acutally the result was a little better than I
  28. : thought.
  29.  
  30. : ALL DMA IS OFF!
  31.  
  32.  
  33. : ;Speed: 5.640 MB/s
  34. (8x load 8x store)
  35.  
  36. : ; Speed: 5.472 MB/s
  37. (movem load, 8x store)
  38.  
  39. huh ? this would equal  "movem load 12 regs slower than normal load".
  40. on 020, movem load is quicker using lot regs. for example I got 9.7 cyc
  41. movem load from chip instead of the usual 12 cyc. 
  42. And in fastmem 4.9 movem load vs. 6.4 normal load.
  43.  
  44. so anyone of us got a bug or 030 is very different here ?
  45.  
  46. : ; Speed: 5.472 MB/s
  47.  
  48. (movem load,movem store)
  49.  
  50. same speed, naturally, chip stores can't be speed up.
  51.  
  52. : ; Speed: 4.896 MB/s
  53. :         move.l  (a0)+,(a1)+
  54.  
  55. : ; Speed: 4.656 MB/s
  56.  
  57. :         move.l  (a0)+,d0
  58. :         move.l  d0,(a1)+
  59.  
  60. so who reported this was faster than ()+,()+ ? :)
  61.  
  62.  
  63. Do those "free c2p" routines really run 5.6 mb/sec ?
  64.  
  65. : >imho this should do 7mb/sec in the store part. if the movem
  66. : >is very fast, you aproximate the 7mb/sec also doing copying.
  67.  
  68. : 7 Mb/s is not possible. Remember that you have to access the same data-bus to
  69. : read from FastRam.
  70.  
  71. I said "very fast cpu" and "aproxiamte 7mb/sec" :)
  72.  
  73. : >On 020-14 it will be slower than normal copy, on 020-28 maybe already
  74. : >faster (only theory!)
  75. : >so we still need a test if it's faster than move.l (fast)+,(chip)+
  76. : >|> Here is my results from bustest:
  77. : >|>
  78. : >|> BusSpeedTest 0.07 (mlelstv) Buffer:    16384 Bytes
  79. : >|> ==================================================
  80. : >|> loop overhead:      4.5ns
  81. : >|> register move:     40.6ns
  82.  
  83. : >huh ? a register move is 2 cycles. you got 24.63 MHz ?
  84.  
  85. : Ehh..No, I have 50 mhz.
  86.  
  87. : I tested it myself. (just to be sure)
  88.  
  89. : I was able to do 24400000 register move's and 203300 dbra's per second.
  90. 2.04 cycles for the reg move.
  91. if the dbra number misses 2 zeros, it's 2.45 cycles/dbra (wow!), if
  92. the "203300" is true, it's 245 cycles (laaaame!)  ;)
  93.  
  94. : A dbra is 3 times slower than a register move so that's 25.0 peek MIPS.
  95. uhm... yep, 6 cycles dbra on 020, too. exactly enough for the 6 free cycles
  96. of a chipmem store.
  97. so on your card rather 8333333 dbra's /sec ;)
  98.  
  99. : 1.000.000.000 ns / 25.009.900 = 39.98 ns
  100. what ?
  101.  
  102. : Check you numbers, its correct!
  103.  
  104. : >|> memtype   op      cycle      bandwidth
  105. : >|> fast      readw   109.1ns   18.3MByte/s
  106. : >|> fast      readl   137.6ns   29.1MByte/s
  107. : >|> fast      readm   167.7ns   23.8MByte/s
  108.  
  109. : >readm slower ? hmhmhmhm. nooo.
  110. : Ohhh-yes.. Just look at the copy results.
  111. mhm how much cycles is move.b (an),dn ?
  112. I hope this improved (other possibility: movem load worse vs. 020)
  113. ??
  114.  
  115. : >maybe you can write in 10 14-mhz cycle parts, i.e 5.672mb/sec theoretic
  116. : >if no dma at all.
  117. : Yes, write 5.6 MB/s to ChipRam with no DMA.
  118. hehe, but with another routine than my theory refered to ;)
  119. the 5.6 mb/sec you get with 8 cycle stores + fastmem loads.
  120. my theory said 10 cycles for move.l (an)+,(an)+, but that one is slower...
  121.  
  122. : We support both 2xN sprite-dithering (1 pass) and normal 2xN (2 pass).
  123.  
  124. : If your render-routine is 25 fps or slower using the 2 pass version
  125. : doesnt matter at all in speed and framerate. You only get a better-looking
  126. : display.
  127. yep. no need for ghost-look doing doom, descent etc.
  128. just intuiscreen, supporting all monitors, or genlock or whatever :)
  129.  
  130. : Can you explain about that monitor side-effects stuff you are talking about.
  131. : Is this something new?
  132. my 1084 shows 2x2 ghost screens well, same goes for my TV over both
  133. SCART and composite video.
  134.  
  135. my friends tv would show some color stripes, i.e. disturbed display.
  136. (could still play xtreme racing :)
  137.  
  138. i.e 1084 -> most users no problemo. ghost-look looks even better
  139. over composite video vs. rgb-port, because of smear (hardware-dither ;)
  140.  
  141. : <sb>Ludde - Amiga Demo Coder
  142. : <sb>Virtual Reality & Official Be developer
  143. : <sb>ludvigp@ifi.uio.no
  144.  
  145.