jdchrist@watcgl.waterloo.edu (Dan Christensen) (05/10/89)
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. Thanks for any help. ---- Dan Christensen, Computer Graphics Lab, jdchrist@watcgl.uwaterloo.ca University of Waterloo, Waterloo, Ont. jdchrist@watcgl.waterloo.edu
tarolli@dragon.SGI.COM (Gary Tarolli) (05/10/89)
In article <9607@watcgl.waterloo.edu>, jdchrist@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).
bam@rudedog.SGI.COM (Brian McClendon) (05/10/89)
In article <32440@sgi.SGI.COM>, tarolli@dragon.SGI.COM (Gary Tarolli) writes: > In article <9607@watcgl.waterloo.edu>, jdchrist@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@rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110 -------------------------------------------------------------------------- "Fuse Exxon" - me