ads@canon.co.uk (Adam Billyard) (04/29/91)
Does anyone have any benchmark figures for 3D polygonal software rendering systems? I'm getting around 18,000 polygons/second on a Sparc 1 and 37,000 polygons/second on a Sparc 2 using a 3751 polygon object (a teapot in a 300x300 viewport). I'm interested in developing simple 3D rendering software; by simple I mean a constant shaded polygon is the only primitive. Point and distant light sources are supported along with a bog standard synthetic camera model. The impetus is to get away from a reliance on 3D support in hardware which is both static and expensive. Its kind of nice to run my stuff on faster machines and see such dramatic speed increases.. More to the point, are there any interactive 3D graphics packages available for Suns/Macs? What sort of rendering rates do they offer? Cheers, Adam. ------------- Adam Billyard, Canon Research Centre Europe, 17/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. ads@canon.co.uk, ads@canon.uucp, ..!mcsun!ukc!uos-ee!canon!ads Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360
reher@ucunix.san.uc.edu (Jay R. Reher) (05/04/91)
Silicon Graphics has an adapter that is supposed to display 3 million Gourad shaded polygons per second. IBM's Risc System / 6000 model 730 can \ display 1 million Gourad Shaded Polygons per second. I worked on the IBM and I couldn't really see my objects being built !! I don't know about suns or macs tho... Jay R. Reher
rthomson@mesa.dsd.es.com (Rich Thomson) (05/04/91)
In article <1991May3.190648.13574@ucunix.san.uc.edu> reher@ucunix.san.uc.edu (Jay R. Reher) writes: > Silicon Graphics has an adapter that is supposed to display 3 million >Gourad shaded polygons per second. I know the VGX can do a million FLAT shaded polygons (triangle meshes with 50 pixels per triangle, actually), but I've never seen anything from them claiming 3 million "polygons" [have to be careful to say exactly how big and what kind of polygon], especially not Gouraud shaded polygons. However, one of the parallel architecture machines (I can't remember if its pixel planes or AT&T pixel machine -- I always get them confused) does claim to be able to do 3 M Phong (note: not Gouraud) shaded polygons. >IBM's Risc System / 6000 model 730 can display 1 million Gourad Shaded >Polygons per second. I saw the 730 at SIGGRAPH and I don't remember them claiming this. Where does this number come from? >I worked on the IBM and I couldn't really see my objects being built !! Can you say "double buffering"? -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) (05/04/91)
In article <1991May3.224900.12807@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes: >>IBM's Risc System / 6000 model 730 can display 1 million Gourad Shaded >>Polygons per second. >I saw the 730 at SIGGRAPH and I don't remember them claiming this. IBM doesn't claim this. IBM does, however, claim an order of magnitude less. >Where does this number come from? Thin air? Marc -- Marc Andreessen___________University of Illinois Materials Research Laboratory Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl
laukee@canon.co.uk (David Lau-Kee) (05/06/91)
rthomson@mesa.dsd.es.com (Rich Thomson) writes: >In article <1991May3.190648.13574@ucunix.san.uc.edu> > reher@ucunix.san.uc.edu (Jay R. Reher) writes: >> Silicon Graphics has an adapter that is supposed to display 3 million >>Gourad shaded polygons per second. >I know the VGX can do a million FLAT shaded polygons (triangle meshes >with 50 pixels per triangle, actually), but I've never seen anything >from them claiming 3 million "polygons" [have to be careful to say >exactly how big and what kind of polygon], especially not Gouraud >shaded polygons. >However, one of the parallel architecture machines (I can't remember >if its pixel planes or AT&T pixel machine -- I always get them >confused) does claim to be able to do 3 M Phong (note: not Gouraud) >shaded polygons. This is the point isn't it, "your polygons aren't the same as my polygons, and even if they were, would they do what I want them to?" 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.] With some new, highly "don't ask me any more, I've been issued with a cyanide capsule" secret techniques (and, errr... one or two caveats), we're getting around half this rate (though only FLAT shading) on a SparcStation 2. But this is *entirely in software* (no hardware support whatsoever), so the code will run happily on the Mac, the NeXT, high-end PCs, etc, limited only by the speed of the CPU and how fast it can move stuff to the framebuffer. If you want "near photorealistic" effects (like complex surface characteristics and "atmospheric effects") in real time then the VGX (and its ilk) are excellent machines. But if you want interactive 3-D applications for the masses then you have to realise that most people aren't going to want to fork out gobs of dosh for high-end, graphics specific hardware if they can get 90% of what they want as software-only solutions on "general purpose", industry standard, heh, workstations, for 10% of the price. The P*x*l Machine is the perfect example of how these huge "how fast you can do polygons" numbers don't always reflect how people want to use the machine. Is anyone actually using other than a "near top-end" p*x*l machine for interactive 3-D work? Would they like to quote their "typical" frame rates for the sort of work they are doing? ...And how much did you say you paid for that? ------------- David Lau-Kee, Canon Research Centre Europe, 17/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. laukee@canon.co.uk, laukee@canon.uucp, ..!mcsun!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360
rthomson@mesa.dsd.es.com (Rich Thomson) (05/07/91)
In article <1991May6.114747.12681@canon.co.uk> laukee@canon.co.uk writes: >The VGX does 1.1 million *GOURAUD* shaded, *PHONG* lighted, Z-buffered, >100 pixel, 3-sided polgons (triangle meshes) per second. The quotations I've all seen refer to flat shaded polygons and not Gouraud shaded polygons with regards to the 1.1 Mp/s. Here are the numbers posted by Kurt Akeley of SGI to comp.benchmarks a while back: : size=8, offset=4, zbuffer(1), events=500000, lighting=1 : running on cashew, GL4DVGX-4.0, Fri Mar 29 15:22:58 1991 : Triangle mesh performance (lighted): : 1 triangles per mesh: 189393 triangles per second : 2 triangles per mesh: 304878 triangles per second : 3 triangles per mesh: 299400 triangles per second : 4 triangles per mesh: 387596 triangles per second : 5 triangles per mesh: 471698 triangles per second : 10 triangles per mesh: 574712 triangles per second : 20 triangles per mesh: 641025 triangles per second : 30 triangles per mesh: 675648 triangles per second : 62 triangles per mesh: 714240 triangles per second : Display listed triangle mesh (lighted): : 62 triangles per mesh: 769181 triangles per second : Display listed triangle mesh (colored): : 62 triangles per mesh: 1020342 triangles per second : Quadrilateral strip performance (lighted): : 31 quads per mesh: 342465 quads per second : Independent triangle performance (lighted): : 1 triangles per mesh: 192307 triangles per second : Triangle mesh performance (flat shaded): : 10 triangles per mesh: 943396 triangles per second : 20 triangles per mesh: 925925 triangles per second : 30 triangles per mesh: 1063787 triangles per second : 62 triangles per mesh: 1086886 triangles per second : Quadrilateral strip performance (flat shaded): : 31 quads per mesh: 420167 quads per second : Independent triangle performance (flat shaded): : 1 triangles per mesh: 280898 triangles per second The 1.1 number is for flat shaded triangle meshes and not Gouraud shaded triangle meshes (which come in at 770K p/s). I don't believe they are phong lighted, either; I believe a simple lighting model was used (the code that generated these numbers was also posted, but I omit it here). I noticed also that you edited out my question asking for information on your claim of 3 Mp/s for the IBM RS6K/730. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
rthomson@mesa.dsd.es.com (Rich Thomson) (05/07/91)
My memory slipped in article <1991May6.234927.17724@dsd.es.com> when I said: >I noticed also that you edited out my question asking for information >on your claim of 3 Mp/s for the IBM RS6K/730. The poster in question originally claimed the 3 Mpolys/s for the SGI machine and has not commented on the source of that statement; see the argument in the above referenced article for the real numbers from SGI's literature. The referred to claim above was originally 1 Mpolys/s which another poster pointed out wasn't what IBM was quoting. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
laukee@canon.co.uk (David Lau-Kee) (05/07/91)
rthomson@mesa.dsd.es.com (Rich Thomson) writes: >In article <1991May6.114747.12681@canon.co.uk> > laukee@canon.co.uk writes: >>The VGX does 1.1 million *GOURAUD* shaded, *PHONG* lighted, Z-buffered, >>100 pixel, 3-sided polgons (triangle meshes) per second. >The quotations I've all seen refer to flat shaded polygons and not >Gouraud shaded polygons with regards to the 1.1 Mp/s. Here are the >numbers posted by Kurt Akeley of SGI to comp.benchmarks a while back: ...benchmarks deleted... >The 1.1 number is for flat shaded triangle meshes and not Gouraud >shaded triangle meshes (which come in at 770K p/s). I don't believe >they are phong lighted, either; I believe a simple lighting model was >used (the code that generated these numbers was also posted, but I >omit it here). >I noticed also that you edited out my question asking for information >on your claim of 3 Mp/s for the IBM RS6K/730. I edited it out because it wasn't my claim and it isn't relevent. Yes I remember seeing the benchmarks, posted after someone disputed the numbers in the SGI promotional literature (I believe SGI were redeemed), shall I bore you by quoting verbatim from that technical report? Yes, I think I shall: "Specifically the 4D/380VGX system delivers ... 1,000,000 Z-buffered 3-sided, Gouraud shaded, Phong lighted polygons per second" (Well, ok then, 1 not 1.1, but the shading is there, as is the lighting and Z-buffering) I don't dispute your sources, or your sums. My point is that these sorts of numbers are in some circumstances nearly meaningless. I don't intend to repeat my argument here, take a look at the rest of <1991May6.114747.12681@canon.co.uk> if you're interested. ------------- David Lau-Kee, Canon Research Centre Europe, 17/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. laukee@canon.co.uk, laukee@canon.uucp, ..!mcsun!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360
matthew@castle.ed.ac.uk (M White) (05/07/91)
In article <1991May6.114747.12681@canon.co.uk> laukee@canon.co.uk writes: [...] >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.] If you are thinking of the demonstration I saw, you are correct in your 35k-60k polygons/sec for a VGX. However, you forgot to mention the 60 frames/second figure which is also displayed during that demo. When double-buffering, the frame sync rate will be a bottleneck for small models. -- Matthew White - Visualisation Support - Edinburgh Parallel Computing Centre "All right, hands up if you think it was a Russian water tentacle." - Abyss
ads@canon.co.uk (Adam Billyard) (05/07/91)
People seem to have lost sight of the question; I know you can buy all sorts of goodies that transform and render polygons jolly quickly. This is IRRELEVANT! There must be someone who reads comp.graphics that has actually implemented a 3D modelling and rendering system. What sort of performance do you get? Is it minutes or milleseconds to render 20k polygon scenes? It really is a simple question. Or does nobody actually implement large 3D graphics system these days? What gives. Adam.
robert@texas.asd.sgi.com (Robert Skinner) (05/08/91)
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
rthomson@mesa.dsd.es.com (Rich Thomson) (05/08/91)
I seem to have confused two different authors, the with the original numbers that I was asking about and David Lau-Kee who posted a followup article. Sorry for confusing them and attributing things to the wrong people. I agree 100% with David when he says: In article <1991May7.090203.18257@canon.co.uk> laukee@canon.co.uk writes: >[...] My point is that these >sorts of numbers are in some circumstances nearly meaningless. This is exactly the impetus that drives the GPC. I've just gotten a copy of the GPC quarterly report at work and I'd say that this is required reading for anybody trying to benchmark performance of real machines. I'd also say that its important to actually *see* the GPC tests running as well as looking at the numbers. Something I'd like to see in the GPC report is a tabular break-down of the models describing number of segments/polyline, average polyline segment length (in screen coordinates), etc. The quarterly report just has a paragraph per model that gives one a rough idea of the contents (i.e. mostly polylines/polygons changes to the viewing through the course of the benchmark, etc). This is good, but I'd still like a program that could tell me statistical information about any BIF file. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
yamo@nas.nasa.gov (Michael Yamasaki) (05/08/91)
Greetings. In article <1991May7.094641.18738@canon.co.uk> ads@canon.co.uk (Adam Billyard) writes: > >There must be someone who reads comp.graphics that has actually >implemented a 3D modelling and rendering system. What sort of >performance do you get? Is it minutes or milleseconds to render 20k >polygon scenes? > Okay. I'll bite. I'm doing visualization of unsteady fluid flow... CFD stuff. I have a 4D/320VGX. I threw some timers in my code and this is what I got. The grid surface is a 64 x 64 array of verticies in 3D. GL calls to qstrip. Count each "quad" as 2 triangles. Gouraud shaded, not lit. Z-buffered. Timed for 100 timesteps. Triangle size varies from a few pixels to thousands of pixels. # of grid surfaces tris total tris/second frames/second tris/frame 1 793,800 157,188 19.8 7938 2 1,586,700 188,444 11.9 15876 3 1,984,500 156,630 7.9 23814 3 2,381,400 141,497 5.9 31752 Great. (so all together now) So What? If this helps you to understand that a VGX is the appropriate thing for your particular application, I'm surprised. It's real world but hardly repeatable. It doesn't use the million other things the VGX can do to make it look wizzy (on the todo list). I think its worth the money the government payed to put it on my desk. But when I need real number crunching I "go to" (distributed processing) the Crays that we have. (I wouldn't buy either machine (VGX or Cray YMP) with my own money ;-) -Yamo- yamo@wk209.nas.nasa.gov yamo@amelia.nas.nasa.gov {ncar, decwrl, hplabs, uunet}!ames!amelia!yamo
yamo@nas.nasa.gov (Michael Yamasaki) (05/08/91)
In article yamo@nas.nasa.gov (Michael Yamasaki) writes: > >The grid surface is a 64 x 64 array of verticies in 3D. >GL calls to qstrip. Count each "quad" as 2 triangles. >Gouraud shaded, not lit. Z-buffered. Timed for 100 timesteps. >Triangle size varies from a few pixels to thousands of pixels. > ># of grid surfaces tris total tris/second frames/second tris/frame > > 1 793,800 157,188 19.8 7938 > 2 1,586,700 188,444 11.9 15876 > 3 1,984,500 156,630 7.9 23814 > 3 2,381,400 141,497 5.9 31752 > Wow. How did I do that? This should read: # of grid surfaces tris total tris/second frames/second tris/frame 1 793,800 157,188 19.8 7938 2 1,587,600 188,551 11.9 15876 3 2,381,400 187,956 7.9 23814 4 3,175,200 188,663 5.9 31752 Just goes to show you can't believe everything you read... -Yamo- yamo@wk209.nas.nasa.gov yamo@amelia.nas.nasa.gov {ncar, decwrl, hplabs, uunet}!ames!amelia!yamo
laukee@canon.co.uk (David Lau-Kee) (05/08/91)
robert@texas.asd.sgi.com (Robert Skinner) writes: >In article <1991May6.114747.12681@canon.co.uk>, laukee@canon.co.uk (David Lau-Kee) writes: >|> ... stuff questioning the applicability of certain benchmarks ... >I won't quote you, but I should point out something about those numbers: ... stuff about frame sync bottlenecks ... Yes, of course everything you say is true. Is this not the point? The discussion started when someone asked about performance for doing simple flat shading on smallish, polygonal models in software, and was answered by discussions about how quick the VGX, et al could do "special effect x, y and z". I have no argument with that, and I don't disbelieve the figures. But it may be worth reiterating that *the usefulness of this is questionable* if my special, souped up engine does operations O1, O2 and O3 very quickly under circumstances C1, C2 and C3, if what was asked for does not call for O1-O3 or if C1-C3 do not hold! Your [deleted] example of the 1 polygon model limiting rendering to 60 polygons/sec proves the point far more eloquently and persuasively than anything I could have come up with. ------------- David Lau-Kee, Canon Research Centre Europe, 17/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. laukee@canon.co.uk, laukee@canon.uucp, ..!mcsun!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360
pmartz@undies.dsd.es.com (Paul Martz) (05/09/91)
I think everyone has the basic idea now that peak performance numbers quoted by marketing departments are pretty mich useless in calculatin ghow fast applications X Y and Z will run on a workstation. An alternate benchmarking method is needed. Robert Skinner suggested in a previous article, "...use *your application* as the benchmark on the the machines you consider purchasing." This is probably the best way to judge your performance for that applcation, but is often impractical for large applications that would require substantial porting to some vendor's proprietary interface. (Now if you've coded to PHIGS or some other standard, this problem is reduced. But anyway...) So something better is needed. I think Rich Thomson mentioned GPC but I don't remember him explaining it very thoroughly. GPC is a benchmarking standard developed by the Graphics Performance Characterization Committee. Basically it allows anyone to code up a simple test file (in a format called BIF -- Benchmark Interchange Format). Some sample BIF files I've seen typically put up several frames, pan and zoom around the object/image, contain lines, local transform matrices, etc. You can make it as complicated as you want. Or if you don't have the resources to write up your own BIF file, there are already several available, and chances are one of them might resemble sample output from the application you'd like to run. The point is, GPC benchmarks can take into account whatever factors you're likely to experience in your application, such as swapping buffers or clearing areas between frames. Many vendors are members of GPC, and are ready to run whatever BIF file a potential customer would like to run. Further information concerning GPC is available through NCGA: NCGA PO Box 3412 McLean, VA 22103-9832 -- -paul pmartz@dsd.es.com Evans & Sutherland