From: dstamp@watserv1.waterloo.edu (Dave Stampe-Psy+Eng) Subject: Re: TECH: Canon Software workstation Date: Tue, 5 May 1992 22:14:46 GMT Message-ID: <1992May5.221446.25948@watserv1.waterloo.edu> Organization: University of Waterloo deering@deering.Eng.Sun.COM (Michael F. Deering) writes: >Punchline: The Cannon ``benchmark'' is assuming much smaller polygons >than typical rendering benchmarks quoted in the graphics industry. > > (1) Overhead of getting the 3D primitive data > (2) Transformation, clip test, face test, lighting, render set-up > (3) Scan converting the individual pixels into the frame buffer Actually, I would rate (1) as nearly free, and (2) as likely to be the most expensive, based on my experience with REND386. When running the 500-poly demo, the average poly size is about 100 pixels, with 250 polys actually rendered. Now about 20% of the render cycle time is spent on screen buffer clearing, 30% on drawing, and 50% on calculations and structure manipulations. If the VGA bottleneck was removed, the render time would be divided between about 80% calculation and 20% drawing. (This is with a 320x200x256 color viewport). >there's the question of what's a polygon. Some systems that can draw >quadralaterals will count this as ``two polygons'', but since even >quadralaterals are rarely complete flat, this would be a cheat unless >the HW/SW can render non-planer quads. Well, then the format should be specified better. But most good renderers are capable of using quads, so why not make them a standard? If the software has to split them, it won't perform as well in real life either. >Software renders tend to spend nearly all their time in (3), at least >when using 100 pixel polygons. Thus any benchmark of a software >renderer is *very* sensitive to the polygon pixel size. True, but if you specify that the image must almost fill the viewport, then normalize by viewport size, you'd get pretty good results. BUT... since math overhead is just as (or more) important, this will throw the scaling off. And not all viewport sizes can be supported by every package. For garage VR, I suggest 320x200; for desktop VR (workstations) I suggest either 640x400 or 400x400. >*BEING-RIDICULESLY-PESSIMISTIC-DON'T-SHOOT-ME-THIS-IS-JUST-AN-EXAMPLE- >OF-WHY-MORE-EXACT-ASSUMPTIONS-ARE-NEEDED*: >Since software renders are typically fill limited (ever for fairly >small pixel count polygons), if one takes the SPARCstation-2 80K >``really for 3750/2 21-pixel polys'' number and derate it by 5 for area >(and 2 for backfacing) we get 8K 100-pixel polys/sec (near what some >people have been getting for years in software on SPARCstations). Taking >the 120K ``25000/2 5.1-pixel polys'' and derate it by 20 for area (and 2 >for backfacing) we get 3.5 K polys/sec. Again, you're underestimating the effect of math on the situation. You should probably derate by less (say 50% to 70% less) because of this. Also, 100-pixel polys are just a guess at real world loads. If you can draw an equivalent area in small or large polys in the same time, it's actually preferable to use small polys because of the finer control and detail this gives you. So in some cases you should actually prorate smaller polys. >To avoid just this sort of specing problem, the graphics community has >started a more realistic benchmark effort: the GPC. Here real application >example geometery (and overhead CPU code) is run as part of the benchmark, >things like polygin size, backfacing, etc. are not stated, you just get >whatever the real application really does. >... It would be interesting to see what the Cannon >system does on the standard GPCmarks. I'm sure the folks at Canon are willing to run these. However, what's wrong with the benchmark they used? They used what I consider a fair example of a workstation type viewport size and object. The fact their polys are'nt an average of 100 pixels just shows how arificial the 100-pixel benchmark is. >However, because immersive VR many times have to cover >all the pixels on the display (e.g. you're in a virtual room), yet keep >a high frame rate, the average size of polygon in many VR systems is >considerably larger than 100 pixels (despite the output being on 640x480 >NTSC rather than 1280x1024). But as rendering speeds for VR imporve, >average VR polygon pixel counts will also start down. Yes, but the larger poly sizes on VR systems are a symptom of the MATH bottleneck, not graphics. The other effect is poly-edge masking, which is only a problem on VGA-based systems due to slow access times. >I'm sure that there are many other neat features of the Cannon system >(for example, I suspect that they may be avoiding using a Z-buffer, are >batching xform and clipping tests, etc.), and if is tunned for VR, not >old MCAD benchmarks, so much the better. I don't mean to down-play the >importance of a significant new entry into virtual worlds software, but >with VR's current public rep we must be carefull about how we make claims. Well, I dunno. They certainly aren't using a Z-buffer, I can vouch for that. They'll be using blitter techniques very much like REND386 for some of their drawing, otherwise they can't access VGA memory fast enough. BUT... still, I say they've done a great job. I estimate their graphics are at least 20%-30% faster than REND386, and their math at least 100% faster. Graphics speed isn't all. For example, REND386's blitter does 18,500 100-pixel polys per second, but overall speed is much more modest-- maybe 5000 polys/sec, including backfaced removal. So graphics is the minor factor here. -------------------------------------------------------------------------- | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware... | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | __________________________________________________________________________