In your message of 13 September 1999 you write:
> 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.
First off, the dispatch is between direct adn indirect and then a
second level between execute and compile and execute.
Then, this paragraph is a response to the idea of letting libGL do
driver dispatching behind the scenes for unknown extensions (a direct
rendering driver would register them, but libGL has the
infrastructure). This might require an additional internal table
lookup, which for very performance sensitive operations (like
glVertex3f) might be just to much overhead.
> [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?
We are talking here about both, the abstract API as well as the
consequences that certain API directions cause at the driver
level. The notion of a driver is something we have to deal with here.
> 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.
True. However the alternative of having glXGetProcAddress() return a
different pointer for every context is just a big nightmare for
application developers.
> 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'?
This is simple under X11. Same driver means essentially same
screen. You basically bind a context at creation time to a screen by
executing glXCreateContext().
> In short:
> - We don't have 'drivers' in the api or spec, and I don't want them.
If it's the word "driver", then replace it by the word "screen".
> - Contexts are well specified and will have to be mastered by those that use
> them.
Right, but given the alternatives of either having different function
pointers for every context (full burdon on the application writer), or
some tricky dispatch in the libGL, having the simpler semantics of
something along the line of "compatible contexts" make
sence. Compatible in this case is same screen and same "directness".
This seems to minimize the complexity for both sides quite a bit.
> - Context dependent pointer results are not a new concept; consider
> glGetString().
Then you have not understood the whole issue. glGetString() is
associated with a context at execution time. However if you first
retrieve the address of a function, then the context is bound before
executing the function.
> - Having 'gl{X}GetProcAddressExt' return a context dependent result provides
>the
> (OpenGL) implementor with more, not less, freedom.
I don't really see that. You still have to go throu an internal
dispatch, which means it doesn't buy anything, as you can do real
driver dependant stuff within this dispatch.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
