At 08:55 AM 10/19/99 -0700, John M. Zulauf wrote:
>
>This is all good stuff. This is the sort of thing an application expects of
>a driver. But you have confused me, because I thought your object to the
>getProc being context independent was driver overhead and complexity of
>implementation. It sound to me like the context dependant implementation
>you've got has all the complexity, overhead, et. al. that you are concerned
>about a context independent version imposing.
Maintaining an internal dispatch table is fairly trivial, and indeed this
code already exists in all/most implementations. In the Windows code,
implementing wglGetProcAddress is as simple as returning the driver-owned
wrapper function which jumps through the dispatch entry.
In a context-independent implementation, we'll have to synthesize a wrapper
function in device independent code, and devise a mechanism whereby the
driver informs the higher level code every time it wishes to change the
dispatch table, and/or update it directly through an additional level of
indirection after registering the entry point with the device-independent
code. In addition, when a new context is bound there must be some
negotiation between the platform-independent code and the driver to sync up
on the location of all extension API's which have been queried thus far.
Further, the platform-independent code doesn't know how many entries to
synthesize in its dispatch table, which might have to be dynamically
reallocated. If we pre-allocate a number of static entries, how many is
enough? Its a can of worms.
Whether or not the overhead and complexity of the latter case is
manageable, my primary objection is that it simply doesn't solve a problem
worth solving, since the application must already manage per-context state
(e.g. is the extension supported?) and the function pointers are one more
piece of state to be stored in some per-context application-level data
structure. Its too much work for too little gain, in my opinion. Yes we
could do it, I just don't think its worth the headache. I firmly believe
that if the mechanism is too complex its probably not designed correctly.
In this case, adding a trivial burden to the application saves the driver
from jumping through hoops, and that makes it feel like the right design.
>(1) It is less convenient. One must retrieve a proc for each context in
>order to use an extension in that context. Since, as we have already
>agreed, the getProc return value cannot be used to verify the exsistance of
>an extension -- there is no value added, and no additional information
>provided to the application by this step. It is simply an extra per-context
>step imposed by a context-dependant specification.
A small price to pay relative to the driver complexity it avoids.
How burdensome is this?
Init() {
myContext = CreateAndBindContext();
myContext->fooIsSupported = QueryExtensionString("GL_EXT_foo");
if (myContext->fooIsSupported) {
myContext->FooEXT = glGetProcAddress("glFooEXT");
}
}
Runtime() {
if (myContext->fooIsSupported) {
(*myContext->FooEXT)(GL_FOO_EXT);
}
}
>(2) It is less capable. The implementation you describe does everything a
>context independant implementation requires (potentially more since you have
>a dispatch step AND a validation step), but simply fails to go the last cm
>and invoke the proper extension proc registered by the driver for the
>current context. The context dependant design seems to require the driver
>implementer to do all of the work relative to a context independent one, but
>not gain all the end-user functionality and convenience.
As I described above, this simply isn't true. The driver support require
for device-independence is much more burdensome than it is for
context-dependent procs.
>On a personal note:
>
>> Does this make me callous? Perhaps.
>> I've certainly been called worse.
>
>You're right I did say your attitude was callous. That's not to say YOU are
>callous (which I didn't say), but it is borderline name-calling.
No worries. =)
>What I should have said is the design criteria you had outlined "a bug is a
>bug, if it crashes... tough" is callous. Clearly from your thoughtful posts
>and how you've described your drivers you don't in fact just say "tough" to
>your user base -- I guess I was trying to point out the cognative dissonance
>of your proposed design criteria and your actual implementation approach.
>(and utterly failing in the attempt)
I tend to be terse and I may indeed come across as callous so I didn't
really mind your remark. Simply put, I think we are over-engineering this
to save application developers a trivial extra step, and it feels like we
are trying to pamper the developers. In fact I believe we would do them a
disservice by hiding the fact that extension procs are indeed
context-dependent in nature and if they plan to support Windows they need
to be aware of this fact anyway. Call it tough love. ;-)
Regards,
-- Michael
