SGI's interesting idea of a "speedup"

[jim frost]

Quoted from "Porting Applications to the IRIS-4D Family":

-- begin quote --

5.3 New Drawing Subroutines

Software reliease 4D1-3.0 introduced several new Graphics Library
subroutines for drawing and pixel access.  Silicon Graphics recommends
converting old style routines to the new ones for three reasons:

    * Your code will be more portable.

    * On the GT and future products, the new subroutines will run up
      to 10 times faster than their old counterparts.

    * The new subroutines simplify the Graphics Library and allow for
      future expansion.

In most cases, the convertion is simple -- just substitute the new
subroutines for the old ones.  Unfortunately, the new subroutines do
not work in display lists, so if your code is based primarily on
display lists, the solution is not so simple.

This table gives a comparison of old and new subroutines.

----------------------------------------------------------------------
Technique		Old Subroutines		New Subroutines
----------------------------------------------------------------------
draw connected		move,draw,draw		bgnline,v3f,v3f,
line segments					endline

draw closed		move,draw,draw		bgnclosedline,v3f,v3f,
hollow polygons		or poly			endclosedline

draw filled		pmv,pdr,pdr,pclos	bgnpolygon,v3f,v3f,
polygons		polf or splf		endpolygon

draw points		pnt,pnt			bgnpoint,v3f,v3f,
						endpoint

read pixels		readpixels,readRGB	rectread,lrectread

write pixels		writepixels,writeRGB	rectwrite,lrectwrite

draw triangular		new			bgntmesh,v3f,v3f,
meshes						endtmesh

color(vector)		RGBcolor		cpack or c3i

surface normal		normal			n3f

clear screen,		clear,zclear		czclear
Z-buffer

create RGB		RGBwritemask		wmpack
writemask
----------------------------------------------------------------------

-- end quote --

Interestingly, the 10x factor seems to be correct as one of our
customers reported that our product "ran ten times slower" on the GT.

We happily followed the SGI guide to speed them up.  At one point we
changed all our readpixel() calls to rectread() calls, a non-trivial
task because they don't have the same arguments at all.  To our great
surprise, the following was printed when the new call was made:

	<rectread> is not implemented.

We were impressed at just how fast their new function didn't work, as
I'm sure you can guess.

Curious, we investigated.  Making use of "strings", we found that
libgl_s.a contained the string "<%s> is not implemented.".  Just how
many functions might call whatever routine has that string is
something that scares me.

Jim Frost
Associative Design Technology
(508) 366-9166
madd at bu-it.bu.edu