jmb@patton.SGI.COM (Jim Barton) (03/08/89)
I'm posting this article in reply to an early article asking how we benchmark our graphics hardware. Direct responses and queries can be sent to kurt@sgi rather than myself. -- jmb =============================================================================== This note is a response to Barry Fowler's message of 15 February 1989. Barry referenced our '88 SIGGRAPH paper (High Performance Polygon Rendering) and asked several questions concerning it and the system that it describes. His questions (paraphrased by me) and our responses are: 1. What system do the benchmark figures in the paper correspond to? They are for the dual-processor GTX (4D-120) product. However, only one of the CPU's is used during the benchmark (the other is available for general purpose computing). 2. Were the benchmark figures computed, or were they measured on actual equipment? We ran the benchmarks on the prototype GTX hardware that was available at the time. I reran the benchmarks on current equipment, and have included the new figures below. 3. Will SGI distribute the binaries of the benchmark programs? Perhaps even source code? We are happy to distribute both binary and source to customers through our sales/service organization. The performance figures claimed in the paper (and the current figures) are: - 101,000 quadrilaterals per second. 100 pixel, arbitrarily rotate, lighted, Z-buffered. (102000, up 1 percent) - 137,000 triangles per second. 50 pixel, arbitrary strip direction, lighted, Z-buffered. (135000, down 1 percent) - 394,000 lines per second. 10 pixel, arbitrarily directed, depthcued, Z-buffered. (334000, down 15 percent) - 210,000 antialiased lines per second. 10 pixel, arbitrarily directed, Z-buffered. (175000, down 17 percent) - 8.3 millisecond full-screen clear. Both color and Z-buffer banks cleared. (8.2, up 1 percent) Current polygon and area fill benchmark results are all within one precent of the figures claimed in the paper. Line drawing rates, however, are down roughly 15 percent from the claimed values. This performance loss is the result of a bug fix correcting the hardware interaction of polygon patterning with line drawing. We expect that future microcode releases will restore the line drawing performance to previously measured values. -- kurt