GLperf is an executable that measures the performance of OpenGL 2D and 3D graphics operations. These operations are low-level primitives (points, lines, triangles, pixels, etc.) rather than entire models like Viewperf.
The purpose of GLperf is two-fold: to standardize the method by which vendors report OpenGL primitive performance on their systems and to provide a much fuller picture than that afforded by isolated primitive numbers through use of interactive graphs and other data analysis tools.
A GLperf script describes what graphics primitives are to be tested, for example, a 50-pixel triangle strip. A script allows many disparate primitives to be tested upon one GLperf "run", and facilitates easy changes and comparisons between different tests.
The OPC has approved a set of 13 GLperf scripts for submission and publication. These are split into 10 RGB scripts and 3 color index scripts. Furthermore, the scripts are divided by functionality: the OPClist scripts (RGB and color index) contain a number of tests for a variety of graphics primitives and other operations (such as window clears). These are probably the closest parallel to primitive-level results available from most vendors today. Other scripts feature a specific graphics operation, for example, CopyPixl.rgb, DrawPixl.rgb, ReadPixl.rgb, TexImage.rgb measure glCopyPixels, glDrawPixels, glReadPixels and glTexImage2D RGB operations. DrawPixl.ndx and ReadPixl.ndx are the color index analogs to DrawPixl.rgb and ReadPixl.rgb. The remaining scripts address underlying graphics concepts that affect OpenGL performance - BgnEnd.rgb measures performance as it varies with the number of primitives batched together (in a glBegin/glEnd pair), FillRate.rgb measures how fast rasterization operations are performed (how many pixels are drawn per second), Light.rgb measures the affect of the number of enabled light sources on drawing a particular primitive, while LineFill.rgb and TriFill.rgb measure the affect of increasing primitive size on the drawing rates of lines and triangles, respectively.
No, the only exception being those vendors whose windowing system or OpenGL implementations don't support the operations being tested. An example of this would be a vendor who windowing system does not support color index windows, only RGB.
This vendor could report all the RGB results, but omit the color index results.
One number is certainly preferable for comparison and marketing purposes. However, it does not serve justice to boil down meaningful results into one meaningless number. Take the analogy of buying a car: one must compare many aspects of each to arrive at the best buying decision. Most car shoppers do not take totally unrelated metrics and composite them for comparison purposes (for example, take an average of the acceleration, top speed, trunk space, fuel efficiency, legroom, gas tank capacity and inverted braking distance), so why would one insist on doing so for something as complex as 3D graphics performance? Rather, one should choose the metrics most related to one's needs and compare using those figures. For example, a CAD user may not care particularly how fast a system can transfer an image from memory to the screen, but this is vitally important to others, for instance, in the film and video industry.
For the initial GLperf submission, 3Dlabs submitted results for one configuration (their GLINT MX Reference board on a Compaq Pentium II workstation), and Silicon Graphics submitted results for six configurations: four Octane systems and two O2 systems.
Although both Viewperf and GLperf measure the graphics performance of a system through the OpenGL API, they were designed with different goals in mind. While Viewperf draws an entire model with differing sizes of primitives (as you would see in an actual application), GLperf artificially assigns a specific size to each and every primitive drawn within a test. While Viewperf attempts to emulate what an application would do graphically and measure it, GLperf makes no such attempt, but offers a much more "controlled" environment to extract and measure the highest performance (or "upper bound") of a particular system. Another difference is that Viewperf reports results in frames drawn per second, whereas GLperf measures its results in primitives drawn per second, whether the primitive be pixels, points, lines, triangles or some other object. To give an analogy to the automotive world, GLperf would be the equivalent of a speedometer measuring top speed, while Viewperf would a stopwatch measuring the average speed through a slalom course.
A substantial amount of work went into making the visualization and analysis of GLperf data as simple as possible. This is realized in the form of Java applets that read the GLperf performance results from the server's database, and allow tabular and graphical comparisons on the client's web browser. At the top level, the GLperf visualization tools are broken into two branches, the OPClist and the other scripts. Going down the OPClist branch, one can construct a performance comparison by selecting the desired primitives from one list, and the desired systems on another list. The other branch allows one to choose from the different GLperf scripts, the data that most interests them. Each choice enables a table to be displayed with "graphs" on one axis and system configurations on the other. By selecting on different cells, different sets of data will be displayed. Also, the axes can be linear or a log scale, allowing the most flexible plotting of data.
Visualization tools user guide
Those systems supporting OpenGL drivers on OS/2, Windows 95, Windows NT and UNIX derivatives.
Comments to: John Spitzer