why is getmatrix() so slow? where is it called?

[Brian McClendon]

In article <32440 at sgi.SGI.COM>, tarolli at dragon.SGI.COM (Gary Tarolli) writes:
> In article <9607 at watcgl.waterloo.edu>, jdchrist at watcgl.waterloo.edu (Dan Christensen) writes:
> > I have a program that repeatedly draws roughly 3000 polygons and updates
> > the matrix stack.  I did a profile of its execution.  The top few lines I
> > received are:
> > 
> > %time     seconds  cum %   cum sec  procedure (file)
> > 
> >  30.7      7.7400   30.7      7.74 normal (normal.c)
> >  29.8      7.5200   60.5     15.26 solidicos80 (spheres.c)
> >  13.1      3.3100   73.7     18.57 gl_getmatrix (getmatrix.c)
> >   4.9      1.2400   78.6     19.81 v3f (sgl2.s)
> > 
> > This is on an Iris 4D/120GTX running release 3.1C.  In no place do I call
> > getmatrix.  Why is it getting called and how come it is occupying the
> > processor over 13% of the time?  Note that normal and v3f are called
> > roughly 9000 times for every time the matrix stack is updated.
> > 
> 
[ stuff about get_matrix deleted ]
> I am curious as to why normal() takes up 30% of the time and v3f only 5%.
> Both of these do the same amount of work, and I would assume you would
> call each the same number of times.  Strange. Also, your solidicos80()
[ more stuff deleted ]

The reason normal() is so much slower than v3f on the GTX is because it still
uses the GT method for passing data to the graphics pipe.  n3f() is the 
performance equivalent for v3f() and should be used for optimal immediate
mode performance.  Switching should knock 6.5 secs off the above benchmark.

(BTW, I also have no idea why gl_getmatrix is getting called - please tell us)
--
			- brian

   --------------------------------------------------------------------------
   Brian McClendon bam at rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110
   --------------------------------------------------------------------------

   "Fuse Exxon" - me