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

[Luca Barbieri]

> Exported function tables reduce the ability of the driver to replace the
> entire dispatch table with a single pointer change for new state
> combinations or rendering modes.  If the app gets a pointer to a
> dispatch table and caches it, the only way for the driver to change how
> commands are dispatched is to edit the entries in the table, which takes
> more memory references and can introduce synchronization issues.
The GL implementation can introduce an indirection through additional
private tables if desired.

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).

Alternatively, the interface could just give out a pointer to a pointer.
In this case, if the application is using C++, then the binding can
define a C++ class with virtual functions, allowing the caller to
implicitly pass a context pointer (like COM in Direct3D does).

> You
> also need to prevent compilers from caching the table pointer or
> individual entry pointers.
Calling any function whose body is not visible causes the compiler to
assume that anything in memory can be changed, so this shouldn't be an
issue (unless the user caches the pointers himself, and that's a bug).
This probably does not hold for C++ vtable-based bindings though,
since I think the compiler can assume the vtable is constant.

> 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 (or because
it checks for NULL).
Calling function pointers on the wrong context results in undefined
behavior (likely a crash).

> As well, app code needs to invoke different
> function pointers for each context it uses, so it needs to know at all
> times which context is current or which set of function pointers is
> active.  This makes writing general-purpose GL-using libraries much more
> awkward.
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.
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.

Trivial libraries with no such pre-created state would just need to
take context and function table pointers.

> Passing GL context pointers to commands means that the commands all have
> to be prepared to perform a context switch.  Restricting context changes
> to a few coarse-grained commands had performance advantages.
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.

Software rendering doesn't need to do anything to switch contexts, and
relatively recent systems with hardware GPUs almost surely support
multithreading and thus need some GPU state switching support anyway.

But anyway, this is a relatively minor problem in OpenGL, unlike all
the issues that are still present and Longs Peak would have fixed.