> > > For CAD type applications, where you have millions of
> > > small triangles and lots of lights, it would be good
> > > to have hardware geometry exposed. But for entertainment
> > > applications (aka. games), it's not that necessary.
> > > A little assembly code in the transformation and lighting
> > > stages can go a long way....
> > ...and does, but we're comparing apples with apples, you are
> > arguing that more geometry performance is possible but games
> > won't need it, only CAD in situations where there is
> > a geometry bottleneck.
> somewhat correct...
> > For a reasonable number of polygons the geometry processing
> > is an onerous load on the CPU which could be spent
> > performing other tasks particularly on game class PCs which
> > have only one processor. The geometry burden is subtracted
> > from the resource available for application i/o and scene
> > description processing.
> well you can say that about all processing....actually we
> find that in many cases much more time is spent doing
> other things...you could argue that scene description
> processing should go into hardware...
> > You could argue that geometry setup isn't cost effective
> > below some watershed where you might free the CPU but have
> > less effective 3D FP, it might still be a big win for most
> > applications but your benchmark will be lower for stuff
> > like CDRS, in anycase the premise is weak, FP dedicated
> > to 3D geometry processing is cheaper/more effective than
> > using a general purpose processor.
> > Simply reserving good geometry performance for CAD
> > applications is an very unconvincing argument.
> > My background is in real-time visual simulation, this
> > is the market which is possibly closest to the demands
> > of real-time games and the geometry requirements are hefty,
> > in fact a lot of the optimisation effort is spent on
> > geometry oriented processing to enhance the scene
> > complexity even on relatively sparse databases
> > because the required frame rates tend to be high.
> I have some background in vis. sim too, not professional, but
> entertainment. I find fill rate much more important than
> geometry requirements and that current CPUs can handle a
> reasonable polygon load.
> > Scenes are always very non linear in their ballance of
> > geometry and fill performance even with large FIFOs,
> > but you can't easily exploit this even if present when
> > using the CPU, you'll always be heavily geometry limited
> > when drawing some portions of your scene with real databases.
> Depends on what databases you are using...entertainment
> apps can reduce polygon count for framerate.
As I've said elsewhere this is circular argument, it's not
a desirable thing, it's artists making do with what they have.
>.. Current Intel
> CPUs provide hundreds of thousands of sustained polygons/second
> in a game. My argument is not that you cannot get more with
> dedicated hardware, it is that you can get very good results
> without dedicated hardware.
> If by non linear you mean you get a few big polygons and
> then a lot of small ones, there are ways to handle this in
> hardware such that the hardware can overlap filling while the
> CPU is crunching the small polygons.
> This is an age old argument, going back to 1989 when I worked
> on Indigo Entry. Machines without geometry processing tend
> to cost less, yet require more CPU horsepower to handle heavy
> polygon loads. This is a tradeoff. Sometimes, if an app
> is CPU bound, it pays to throw all the money at the CPU
> and do the geometry processing there (offloading 10% of the CPU
> workload won't do much). Different machines are good at
> different workloads. I believe graphics without geometry
> are still valid contendors for many workloads. Note, I did not
> say all.
I agree with most of this, the same topics do keep
getting revisited. I will say that geometry
acceleration will clearly wind up in hardware before
scene graph processing. And the distinction between
geometry in CPU vs HW certainly doesn't lie with games,
if anything games are a justification for HW geometry
acceleration. CAD on the other hand is much more likely
to better utilise CPU performance due to the typically
low overhead of scene processing at interactive frame
rates (until you start getting smart with an API like
optimizer). So let's not confuse the need for more
performance driving HW purchases with what's the
balanced thing to do for an application on limited
You say the HW can overlap filling while the CPU is
crunching, but to make this work well you need a large
FIFO and it doesn't help where you have large numbers
small polys. It's also hard for an application to exploit
the CPU during significantly fill limited portions of
the scene once the graphics blocks.