Thomas Roell wrote:
>
> In your message of 11 September 1999 you write:
>
> > Thomas Roell writes:
> > > It's still an ugly problem. For an application programmers point of
> > > view, I really don't like the idea of GetProcAddress() be dependant
> > > upon the context it's called under. It's just a nightmare and a
> > > predictable recipe for disaster. On the other hand, letting libGL do
> > > the indirection for unknown extensions is very tricky.
> >
> > And potentially slow?
>
> Exactly. And if you want to use this pointer scheme for core-functions
> as well (glVertex3f), then it might be unacceptable.
Use of the pointer scheme is clearly optional for in-core functions. It isn't
clear to me that a slowdown is to be expected if these pointers are used. The
only dispatch that Mesa needs to do at the glVertex level is between direct and
indirect contexts - so in our case a speedup is a possible result of its use at
the glVertex level.
[In another mail by the same author]
> I would also follow the windows semantics here of not being context
> dependant, but driver dependant, which means in our case, that if two
> contexts are created for the same X11-Screen (or whatever the
> equivalents for the emulated GLX cases are), then the pointer returned
> by glXGetProcAddressEXT() should be identical. This takes care of the
> multi-context issues, and makes it also easy on the driver side to
> have multiple different graphics boards (as they can return different
> pointers). If a driver needs to brank to different routines for
> different GLXVisuals, it still can do that behind the scenes. If an
> application uses multiple screens, then only a little burdon is added.
> This seems to be more implementable than a difficult dispatch scheme.
I am more interested in getting it right than duplicating the mistakes of another
platform.
There is no concept of a 'driver' in the GL or GLX api's - the concept of context
hides this and other details completely. Why do you want to introduce a new
concept which doesn't extend the reach of the api?
You talk about X screens - does a direct context on a particular screen count as
the same 'driver' as an indirect context on the same screen? If so then drivers
are weak concepts indeed.
Finally you state that 'If an application uses multiple screens, then only a
little burdon is added'. But surely that burden is exactly the same as the
multiple context case of deciding which table of function pointers must be used
in a given context. In fact it is more complex in your case because you have to
figure out what 'driver' each context belongs to before you know what function
pointer to call. How can an application tell whether two contexts have the same
'driver'?
In short:
- We don't have 'drivers' in the api or spec, and I don't want them.
- Contexts are well specified and will have to be mastered by those that use
them.
- Context dependent pointer results are not a new concept; consider
glGetString().
- Having 'gl{X}GetProcAddressExt' return a context dependent result provides
the
(OpenGL) implementor with more, not less, freedom.
- 'drivers' don't remove the need for applications to do their own branching if
they use multiple contexts, except in some hard-to-define special cases.
Keith
