[Mesa-dev] [Bug 30172] GL_EXT_framebuffer_blit function required

[Allen Akin]

On Sat, Sep 18, 2010 at 01:06:52AM +0200, Luca Barbieri wrote:
| The GL implementation can introduce an indirection through additional
| private tables if desired.

At additional cost in performance, of course.

| Also, display lists might be better designed as something that creates
| a new context, since that's the major use of function pointer
| replacements (Direct3D 11 does that with deferred contexts).

Or any of a number of other approaches.  No argument here; I was just
revisiting the history.

| > Context-dependent function pointers introduce an entirely new class of
| > error conditions.  For example, what do you do when a context-specific
| > command can be invoked on a context whose driver doesn't even have an
| > entry point for it?
| In that case the pointer will be NULL, and non-buggy applications will
| not call it because the related extension is not supported...

The point was that calling a context-dependent function when an
inappropriate context is current creates an entirely new class of error,
with potential for entirely new bad behaviors.  Implementations
generally weren't allowed to go completely insane on error, so they had
to be prepared to keep this case from exploding even though the cause
was a buggy app.  Doing so incurred costs on the normal code paths.

Where you want to draw the line with this sort of sanity guarantee is
certainly debatable, and some things have moved the line since
context-independent pointers were introduced.

| Not necessarily: any non-trivial library depends on being called on a
| specific context anyway, since it will need to have created VBOs,
| textures, shaders and so on ahead of time.

As written, that hinges on the definition of "non-trivial."  But there
are plenty of other complications; for example, interactions between
multiple independent libraries.

| Thus, the library can just store the context pointer and function
| tables in the same structure it uses to hold pointers to those
| per-context resources.

In short, it can duplicate what the driver has to do, but without some
of the information and procedural hooks the driver has. :-)

| You can have multiple current contexts anyway if the application uses
| multiple threads.
| Being able to intermix contexts in a single thread doesn't seem to be
| harder than supporting multiple threads, each with his own context.

Depends on the hardware (CPU as well as GPU).  We're talking history
here, not necessarily current day.

Allen