From: deering@deering.Eng.Sun.COM (Michael F. Deering) Subject: Re: TECH: Canon Software workstation Date: 7 May 1992 03:45:27 GMT Message-ID: Organization: Sun Microsystems, Mt. View, Ca. My original analysis of 3D rendering performance was in reference to a wide range of implementations - from software to dedicated VLSI. One has to keep in mind the differences between these, as the bottleneck will move around. In hardware systems, just getting the data to the drawing pipeline has many times been THE bottleneck. For a software implementation one has to ask if the floating point performance of the CPU was balanced. The Canon system described both an x86 implementation (light floating point) as well as a SPARCstation 2 (fairly heavy floating point). The application doesn't have to use FP, but if it does, and is doing the pixel rendering via a software Z-buffer, and is rendering 100 pixel triangles (which is the commonly used industrial benchmark size), then scan conversion is the bottleneck. It is so much the bottleneck that one might as well use smaller polygons in actual practice; but if one wants to relate Canon's performance numbers to *almost any other* poly/sec numbers you've heard, then you had better normalize their benchmark. 3D workstation benchmarks are probably not the best benchmarks for VR, and I'm sure that the VR community will in time come up with their own benchmarks for rendering. However a *lot* of data and analysis is available for the existing benchmarks, you can't dismiss them out of hand and then still compare polygon/sec numbers for an arbitrary (under specified) new benchmark with the old ones. Another important trade-off that one must keep in mind is the generality of the data that can be rendered. In the quest for speed the rendering algorithms may overly restrict the geometry to be rendered, precluding many potential applications. BSP and other non Z-buffer techniques have been around a long time (longer than the Z-buffer), yet *no* implementation of a fast general industrial graphics package (for the API's of PHIGS, PEX, GL, XGL, HOOPS, etc.) that I am aware of uses them. (I'm talking about interactive shaded 3D graphics, not raytracing) (If anyone knows of any I'd really like hear about them.) Non Z-buffer techniques have been exploited in specialized areas such as flight simulation (the Aviator(tm) program on Sun's), and in several VR packages (Sense8's). Some applications are able to accept the rendering restrictions in trade for speed; many others cannot. This is why one must be careful about specifying what a package can do, and not just give a raw poly/sec number. (Of course, with hardware costs rapidly falling, soft/hard Z-buffers will eventually be inexpensive enough to be used even in low end systems.) For many years the practice in 3D computer graphics was for each company to create its own benchmark for each machine (usually such that floating point and rendering was balanced). If we start out to create our VR benchmarks by biasing them to particular software implementations on current machines we're going down the same path. But as other respondents have pointed out, there's a lot more places to pick up speed in 3D graphics for VR than just pixel filling. Level of detail culling, visibility culling, and conectivity information can all reduce the amount of data to even enter the render pipeline (though once again at the cost of generality). These techniques also improve the speed of mega-poly/sec HW renders, so creating VR geometry interchange format at a better level than DFX files will benefit all (so long as the format is public ;-) ). Michael Deering Email: Michael.Deering@Eng.Sun.COM Sun Microsystems Phone: (415) 336-3017 Mountain View, CA