"John M. Zulauf" wrote: > > ----- Original Message ----- > From: Michael I Gold <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, September 16, 1999 1:37 PM > Subject: Re: [oglbase-discuss] OK, back to Re: 2nd draft: > GL_EXT_get_proc_address spec > > > At 01:46 PM 9/16/99 -0600, you wrote: > > > > > >What I've been trying to say with this approach does have bearing on the > ABI > > >spec though. I think it's a bad idea to return context-specific function > > >pointers from the proposed gl*GetProcAddress function. The only valid > > >objection I've heard to returning a context-independant pointer is that > it > > >would adversely affect performance. So my venture into the architecture > > >realm was to show that such an architecture could be high performance, > > >therefore, performance degradation was not a valid argument for a poor > > >design decision (i.e. returning context-specific pointers). > > > > I don't see a way around the double-indirection, however. Consider > > per-vertex calls such as MultiTexCoord2fvARB(), you're adding another > > branch indirect per vertex. I do believe this will be measurable and > > therefore to be avoided. > > Am I missing something, or doesn't the idea of using context neutral wrapper > procs solve this? Imagine getProc returns (for an unknown extension) one of > a number of "wrapper" procs (where <number> ranges from 0 to MAX) > > wrapper_<number>(args) > context->extra[<number>].proc(args) > > and when faced with an unknown (to libGL) extension available in the driver, > have getProc return the address of the next available wrapper function and > fill in the entry in an "extra extensions" structure (the context specific > proc, and any other information need to manage that proc (EXT id for > example). Then the driver can manage the extra proc similarly to if it > where in the regular dispatch table, right? Yes! This is the general idea I've been trying to describe. This isn't how I would implement it (see a few posts back for that), but it captures the general idea. Again, the main point is that it's possible to reduce the number of indirections to exactly *one* in both cases (call through pointer returned from getProc or direct call), *without* requiring the getProc pointer to be context specific. Therefore, we shouldn't hobble the spec with such a requirement. > Again this is a architectural discussion motivated by the desiring to NOT go > down the road of context (or even display) specific function procs from > getProc. If a problem can be solved in implementation, we can avoid causing > one in the specification. Amen, halleluiah, and well put! Cheers!
begin:vcard n:Johnson;Brett x-mozilla-html:FALSE org:Hewlett-Packard;Worstation Systems Lab adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] title:WSL Turtle Master fn:Brett Johnson end:vcard
