From: Bryan Meredith <bryan@bear-mountain.demon.co.uk>
  To  : ggi-develop@eskimo.com
  Date: Thu, 04 Feb 1999 00:19:45 +0000

Re: libggi3d non-clarity

Jon M. Taylor wrote:
> 
> On Wed, 3 Feb 1999, Aaron Gaudio wrote:
> 
> >
> > And lo, the chronicles report that Bryan Meredith spake thusly unto the masses:
> > >
> > > (I expect this to be ripped apart but if it gets us going, I dont mind)
> > >
> > > Plan A:
> > >
> > > An integer interface descriptor and an integer module descriptor.
> > >
> > > The interface descriptor does just what it says.
> > > i.e.
> > > interface one takes a single 2d coordinate,
> > > interface two takes a single 3d coordinate
> > > and so on. Using an integer should allow us to grow to support whatever.
> > > By querying a module for its input and output interface descriptors it
> > > should be easy for some higher level module to join these components
> > > together. Several 'translators' could also be constructed in order to
> > > change one interface to another in order to enable all sorts of modules
> > > to be plugged together.
> > >
> > > The module descriptor consists of a number which says - phong lighting,
> > > 32bit rasteriser and so on with a bit to say whether this is hardware
> > > accelerated or not.
> >
> > The problem I have with this is that you are limiting module authors
> > to what GGI3D has defined for "standard" interfaces.
> 
>         Well, a GGI3D interface is just a unidirectional mapping from one
> data structure to another, so this reduces to LibGGI3D needing a standard
> set of data structures, which is not as restrictive but still unnecessary
> if you use an IDL.
>

But what do we use for the IDL???
Below I mention the list (or map) of modules by function with input and
output interfaces specified using ints. Text is all very nice but int
compares are faster.
I am a little fuzzy on how this would limit developers to 'standard'
interfaces. For the modules to be pluggable in an arbitrary position
(even if this doesn't make sense), the 'standard interfaces' have to be
there - unless, of course, you are developing a totally custom pipeline
which does not interface with any existing modules. This would lead to a
large (dare I say bloated) registry of standard interfaces. However, I
would expect the interface types to settle at some point. No way 32 bits
worth though ;-)

The alternative is to have each module capable of interpreting an
interface and supplying the approriate data - but surely not.
 
> > I don't think this
> > is necessary, because the only thing GGI3D is going to use the interfaces
> > for is to ensure that the output from one module is in the same format as
> > the input for the next module in the pipeline. Therefore, from GGI3D's
> > perspective, interfaces are completely arbitrary.

Yes.
However, runtime pipeline construction will need to know what they are
in order to do the connecting.

> >
> > I think we should input and output interfaces to be either structs
> > or primitive types (in other words, structs or typedefs), where the
> > structs can be arbitrarily defined, this process is much easier.
> 
>         Yes.

	Yes.

> 
> > For example:
> > Module A has an input type of ggi3d_coord3 <three dimensional coordinate,
> > standard type> and and output type of ggi3d_coord2 <2 dimensional coordinate,
> > standard type>, then it becomes obvious that for a module to be chained
> > after Module A, it has to have an input type of ggi3d_coord2. But you are
> > not limited to standard types. You could just as easily have this (pardon
> > any C++isms):
> 

Is my English that crap???
I thought that I had also said this???


>         I expect that the bulk of high-level GGI3D work will be done in
> OOP languages via CORBA anyway.  It is the natural way to do things using
> the GGI3D approach.  Only the stock LibGGI3D modules which need speed
> above all else will be written in C and assembly language and bound
> together with lower-level IDLs and ORBs.  Actually, you could say that at
> the low levels LibGGI3D is its own ORB.
> 
> [pseudocode snipped]
> 
> > This is by no means my suggestiong for standard types, actual
> > formats, etc; just an example of the model I'm thinking of.
> 
>         That's fairly close to what I had in mind.
> 
> > > Plan B:
> > >
> > > A similar thing but using printf style formatting strings.
> > > i.e.
> > > "xy" takes a single 2d coordinate.
> > > "xyz" takes a single 3d coordinate and so on.
> >
> > I think if we are to go with strings, then they should simply be the
> > names of the types, for instance, ggi3D_coord2 and ggi3D_coord3, respectively.
> > As long as we restrict input and output to single types, there is no
> > need for name-mangling. In otherwords, what normally might be two arguments
> > (for instance, array of 3d coordinates and a number which is the size
> > of the array) will be marshalled into a single type (a struct containing
> > an array of 3d coordinates and a number of the size of that array). Most
> > of the usual types should be standardized (within the ggi3D_ namespace)
> > but the system will not be limited to standard types. As long as namespace
> > rules are followed, there should not be any conflict among different
> > non-standard module interfaces.
> 
>         Yes.
>
> > > I feel that a number based system would be faster as they can be acted
> > > on directly.
> > >
> > > Compilation will yeild a set of usable modules. At this time, a
> > > configuration list or map which details these modules could be
> > > generated. That will allow the runtime system to have a menu on hand. A
> > > runtime registration function should also be provided which will allow
> > > developers to register their own custom modules, equipped with suitable
> > > interface descriptions of course.
> >
> > I think there should be some facility to add new modules to the default
> > configuration, so that at init time, those modules are included, rather
> > than forcing the application or (more likely) the module vendor to
> > include them explicitely. This is especially true for the module vendors,
> > which may have no connection to the aplication or API using the modules
> > (for instance, if I install some new TNT-accelerated modules, this has
> > to be transparent to the application using GGI3D).
> 

This modules map whould be read in when the system fires up. There is no
problem with an application adding entries to it in order to register
new modules. If you want more modules available without runtime
addition, update the modules map before the system fires up.

>         See my other post where I talk about a pipeline optimizer utility.
> All you have to do is make the module available by registering it with a
> global LibGGI3D module registry and re-benchmark your module set.  Your
> new module will now be made use of as best it possibly can be, given your
> current system.  Perfect optimization without any need to know what goes
> on inside the components.
> 
> > > Once this is in place, a higher level policy module (or arbitrator)
> > > would be responsible for connecting the pipeline together based upon
> > > requests from the developer.
> > > i.e.
> > > depth buffer, flat shading etc.
> > >
> > > Because this is a module based system, the developer should be able to
> > > access various modules directly but after a request to the policy
> > > module.
> > > i.e.
> > > give me a 8 bit rasteriser with this interface spec.
> > > give me a hardware text renderer with this interface spec.
> > >
> > > Part of the policy modules' task would be to fit suitable translators to
> > > an existing module in order to fit the request.
> >
> > These are all good ideas, except I think a descriptor-based system based
> > on ints is not flexible enough to support new features and arbitrary
> > interface types.
> 
>         No it isn't.
> 

But why?
There has to be a unique identifier for the each interface. An int
provides millions.
Designed a new module type? Have a new module type identifier (again,
millions)

If you could explain this one to me, I would appreciate it. I see no
problem with your approach (as it is what I am thinking anyway) but I
would like to understand why my specific approach is not optimal, for
whatever reason.
Don't be kind to me, be thorough (but a little kind if poss.)

> > However, if efficiency is a concern with interfaces,
> > then the char*s could be changed to fixed-size char[]s which could be
> > compared directly with memcmp instead of strcmp, if that gains anything
> > significant.
> 
>         Yes again.  You have a really good grasp on what I am after with
> GGI3D, Aaron.  Might you be interested in getting a developer's read/write
> account for the GGI CVS tree from Emmanuel and hacking LibGGI3D a bit?
> Just to implement some of these ideas we've been throwing around here
> since it seems that a rough consensus is forming.  No need to write more
> modules than you need to develop the interface.  I'd do it myself, but I
> simply do not have any free time anymore with my new job.  If I do GGI
> work, it needs to be KGI drivers and Mesa targets right now.
> 
>         But if LibGGI3D was working to the point that I could write a Mesa
> target for *it* and then proceed to write a bunch of GGI3D modules for
> each KGI driver, that would set LibGGI3D on the road to consuming Mesa
> from within like I've mentioned before.  At that point I could justify
> working on it as part of my job again.  So if Aaron (or anyone else, for
> that matter) wants to see LibGGI3D succeed, pitch in and do some work on
> it.  Don't forget to keep testing LibGGI and KGI, though!  We still need
> to get LibGGI 2.0 final out the door.  I'll be ready to build GGI on my
> box at Creative probably tomorrow, so I'll be able to send lots of bug
> reports myself.
> 
> Jon

Forgot to join in with the congrats - good for you!

Bryan
-- 

Oh Bugger...