Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!mips!sgi!shinobu!fido.wpd.sgi.com!texas.asd.sgi.com!robert From: robert@texas.asd.sgi.com (Robert Skinner) Newsgroups: comp.graphics Subject: Re: Rendering performance Message-ID: <1991May7.190509.23004@fido.wpd.sgi.com> Date: 7 May 91 19:05:09 GMT References: <1991Apr29.162712.1905@canon.co.uk> <1991May3.190648.13574@ucunix.san.uc.edu> <1991May3.224900.12807@dsd.es.com> <1991May6.114747.12681@canon.co.uk> Sender: news@fido.wpd.sgi.com (Usenet News Admin) Reply-To: robert@sgi.com Organization: Silicon Graphics Inc., Advanced Systems Division Lines: 60 In article <1991May6.114747.12681@canon.co.uk>, laukee@canon.co.uk (David Lau-Kee) writes: |> |> The VGX does 1.1 million *GOURAUD* shaded, *PHONG* lighted, Z-buffered, |> 100 pixel, 3-sided polgons (triangle meshes) per second. |> |> But how useful is this? If you do some benchmarking on typical interactive |> manipulation of smallish (1k-2k) 3-D models you get around 35-60k |> polygons / second on a VGX. [Don't quote me, this is from memory.] |> I won't quote you, but I should point out something about those numbers: If you are doing "typical interactive manipulation" of N polygons, you execute a swapbuffer() command to synch with the vertical retrace. If a graphics engine can render N polygons *in less than one frame*, then it ends up waiting at the swapbuffer(), and your application (or benchmark ) is limited to 60N polygons/sec (N polygons/frame * 60 frames/sec). Thus, I can construct an "interactive" benchmark that proves that all high-performance workstations can render only 60 polygons/sec, by drawing only one polygon and waiting for the retrace. Your numbers look suspiciously close to a frame rate of 30 frames/sec (1-2K polygons/frame * 30 frames/sec = 30-60K polygons/sec). I admit that I would have expected 60 frames/sec, but its not hard to get off by a factor of two. If the graphics engine takes 1.00001 frames to draw the scene, you have to wait two frames, and apparent through-put drops by half. That's why SGI (and other workstation manufacturer's, I'm sure) benchmarks don't include interactive factors. The benchmarks are an indication of the relative performance of the system's parameters: transform rate, fill rate, etc. They can be used as a general yardstick to compare different workstations, or to estimate whether your particular application will be transform bound, fill rate bound, etc. SGI has always recommended that you use *your application* as the benchmark on the the machines you consider purchasing. That's the only real benchmark that matters to you, right?. But no graphics company can afford not to publish benchmarks that show their equipment in the best light. If they don't the competition will beat them up with their benchmarks, and there will always be the customers that use a benchmark as a primary purchase consideration. disclaimer: I don't speak for SGI's benchmarking philosophy, and I'm not responsible for creating benchmarks. The first half of this message was just common engineering sense. The second half respresents lessons I learned working for another (now defunct) workstation company, when a competitor (also now defunct) started publishing a benchmark that was so meaningless it was funny, in retrospect. It wasn't funny when we were defending ourselves against it. -- Robert Skinner robert@sgi.com "Have you ever danced with the devil in the pale moonlight?" - The Joker