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

[Gary Tarolli]

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.
> 

I do not know why gl_getmatrix is being called.  The easy way to find out
is to use the -invoc option to prof.  Also specify "-only gl_getmatrix".
This will show you who called gl_getmatrix and from where.  You might have
to trace back several levels, ie gl_getmatrix is probably called from
getmatrix, so then you trace back getmatrix to see where it is called from.
If its called from another GL routine, continue tracing.  After a minute
or two of using prof, you should have your answer.

As to why getmatrix is so slow, its because the matrix is stored in hardware.
Getting the matrix out of hardware takes time.  Our graphics pipelines are
set up to take data at a fast rate, but do not return data to the host
quite so fast.  I think getmatrix takes about 100 microseconds or so on a
GT class machine.  On the slowest machines its about 300 microseconds.
This is a reasonable speed for getmatrix. However, I agree that your program
should not be calling getmatrix so often.  

Apparently, some GL routine that
you are calling is calling getmatrix. I can only guess that maybe you are
using lighting models, and are perhaps calling a lighting routine that
either uses the matrix stack as a matrix multiplier (and getmatrix returns
the result), or the lighting routine needs a copy of the some view/projection
matrix so it calls getmatrix.  In either case, you might be able to solve
the problem by finding out which lighting routine calls getmatrix, and
perhaps move that call outside the drawing loop.  For example, you may be
rebinding either the lighting model or a light too often.  It might be
possible to only bind these once.

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()
routine is taking up a lot of time and looks like a good place for some
table lookup optimizations if you haven't already done so. If you are
generating circles and spheres, you can usually store the sin/cos values
in a table (or multiple tables for multiple precision circles), and then
generate the spheres from the tables. The spheres can be scaled, rotated,
and translated to wherever they are needed and however big you desire
them to be, by just modifying the matrix before drawing the unit sphere.
I'm only guessing at what your application is doing, based on the routine
name and the file name (spheres.c).