home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sgi / 12784 < prev    next >
Encoding:
Internet Message Format  |  1992-08-22  |  2.8 KB
  1. Path: sparky!uunet!ogicse!plains!news.u.washington.edu!milton!chuckb
  2. From: chuckb@milton.u.washington.edu (Chuck Bass)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Fastest way to transform points???
  5. Message-ID: <chuckb.714532056@milton>
  6. Date: 23 Aug 92 01:07:36 GMT
  7. Article-I.D.: milton.chuckb.714532056
  8. Sender: news@u.washington.edu (USENET News System)
  9. Organization: University of Washington
  10. Lines: 80
  11.  
  12. I recently attempted to speed up some things that I was doing.
  13. Namely I wanted to decrease a bottleneck's effect.  I found I
  14. was transforming points and multiplying matrices a lot.
  15.  
  16. I us a standard matrix multiplier for this purpose.  IE unrolled
  17. 4x4 matrix multiply.
  18.  
  19. I attempted to improve performace using something like
  20.  
  21.      pushmatrix();
  22.          loadmatrix(M1);
  23.     multmatrix(M2);
  24.         getmatrix(M3);
  25.     popmatrix();
  26.  
  27.  
  28. This fragment turns  out to be about 1/3 the speed of my 4x4
  29. matrix multiply
  30.  
  31. 100000 mat multiplies   took 2.51 seconds
  32. 100000 point transforms took 0.76 seconds
  33. 100000 sgmat multiplies took 11.27 seconds
  34.  
  35. The 1.05 second case is uses stack manipulations.  I rewrote the
  36. code to only do the following:
  37.  
  38.     multmatrix(M2)
  39.  
  40. This code did the following:
  41.  
  42. 100000 mat multiplies   took 2.51 seconds 
  43. 100000 point transforms took 0.76 seconds
  44. 100000 sgmat multiplies took 2.45 seconds
  45.   
  46.  
  47. This leads me to believe that there is no hardware involved in
  48. the stack multmatrix routine.  I suspect that the difference in
  49. performance is because of the matrix inversion that takes place
  50. when a loadmatrix call is made.
  51.  
  52. These results seem to be somewhat consistant.  IE a point takes
  53. around 1/4th the time of a matrix multiply.  (I did do an sginap
  54. after I opend the window to give the window manager a chance to
  55. open the window etc)
  56.  
  57. These results are for on a PI 4D25 (the 4D35 gives similar
  58. results only faster) hinv says:
  59.     1 20 MHZ IP6 Processor
  60.     FPU: MIPS R2010A/R3010 VLSI Floating Point Chip
  61.     Revision: 2.0
  62.     CPU: MIPS R2000A/R3000 Processor Chip Revision: 2.0
  63.     On-board serial ports: 2
  64.     Data cache size: 32 Kbytes
  65.     Instruction cache size: 64 Kbytes
  66.     Main memory size: 16 Mbytes
  67.     Integral Ethernet: ec0, version 0
  68.     Genlock option installed
  69.     Tape drive: unit 2 on SCSI controller 0: QIC 150
  70.     Disk drive: unit 1 on SCSI controller 0
  71.     Integral SCSI controller 0: Version WD33C93A
  72.     Graphics board: GR1.2 Bit-plane, Z-buffer, Turbo options
  73.     installed
  74.  
  75. My question is.  Is there a faster way using some of the "built
  76. in matrix 'stuff'"?  If there is not are there faster ways of
  77. making the transform.  I know I can reduce it to a 4x3 matrix
  78. multiply for a gain of 25%.  Are there other such optimizations?
  79.  
  80.  
  81. Thanks,
  82.  
  83.  
  84. Chuck Bass
  85. College of Forest Systems Engineering
  86. University of Washington
  87. chuckb@u.washington.edu
  88.  
  89. PS  I need to transform the points to do collision detection.
  90. Currently the function clipbox is not implemented on our
  91. machine ;-(.  
  92.