From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 3 Feb 1999 13:55:59 -0800 (PST)

Re: libggi3d non-clarity

On Wed, 3 Feb 1999, Tristan Wibberley wrote:

> 
> 
> On Tue, 2 Feb 1999, Aaron Gaudio wrote:
> 
> > And lo, the chronicles report that Xavier Bouchoux spake thusly unto the masses:
> 
> [snippage]

	Wow, I am unable to keep up with all the LibGGI3D discussions! 
Marcus is right, we *need* at least one additional mailing list.  I might 
be able to host it at Creative if nowhere else.  I'll ask my boss.
 
> > > - a way to know which modules are hardware accelerated
> > >       (actually, that doesn't means a lot.  The actual thing is more a
> > > way of knowing wich module is faster, and how fast they are. In order
> > > for the app to decide if it can use them or not.)
> > 
> > Hmm...I don't think there is a clean way of telling which module is
> > actually faster. That is heavily platform dependant and could in fact
> > change depending on the situation. You'd actually lose more time trying
> > to test which modules or groups of modules is most efficient than if you
> > just picked one randomly (in fact, that's provable).
> 
> An install time test can do this, put the results into a file. If the app
> asks to know about the performances, load the file. The file would have to
> store data about the system (CPU info, RAM, Video Board - one file for
> each system and a utility to clean up the unneeded data).

	A general-purpose pipeline benchmarking utility would be what we
would need here, IMHO.  It would take an input and output interface and
exhaustively benchmark all possible rendering paths based on the installed
module set.  Then you would be able to have the utility set up static
pipeline "maps" based on the benchmarking results.  Perhaps sub-benchmarks
of some sort could be specified for OpenGL/Mesa, Direct3D, VRML, or
whatever other common APIs would need to be re-banched a lot.  Or these
APIs could come with their own benchmarking utility, or whatever.  The
basic idea is still the same. 

	I mentioned this same idea way back when I first posted the new
LibGGI3D RFC, and I still think it is a critical element that will make
LibGGI3D shine.  Whenever you download a new module, you rerun the
pipeline optimizer to ensure that the new component is maximally utilized. 
Depending on how far you wanted to take this concept, the pipeline
optimizer might even be able to to wacky stuff like use yacc to construct
its own arbitrator modules!  Remember, LibGGI3D pipelines are
unidirectional, acyclic graphs, so in theory a shortest path algorithm
should be able to be applied to find the optimal modules set to make up
your pipeline.

> > However, it is
> > often very important to know if a module will use hardware acceleration
> > to do its job. This will often determine whether you use that module or
> > not (for instance, you probably don't want unaccelerated bump-mapping to
> > be in the mainstream pipeline).
> 
> What if you're on a processor that's really good, and the video card
> isn't. You want to do SW rendering all the way - but the app can't know
> that.

	Right, but the pipeline optimizer above should be able to pick 
that sort of thing up and handle it without any problems.  As long as all 
your hardware accelerations have GGI3D modules that encapsulate their 
functionality installed on your system, the optimizer should be able to 
pick the best module layout every time.
 
> > > I think that the pipeline should be built dynamically at run time (It
> > > can be computationally expensive: it is run only once!)  because that's
> > > one advandage of libggi3D when not using high level API (only). 
> > > With (as an option) configuration files, to skip this step for usual API
> > > (openGL has its pipeline built only once).
> 
> I think both would be good. Let the app choose with #defines whether the
> pipeline should be built at runtime or compiletime.

	I do not think that these two are really the same thing at all. 
Runtime optimization can be done statically with a pipeline optimizer, and
compile-time optimization is really just another term for an arbitrator
module that has a lot of intelligence as part of its design.

Jon 

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed