> 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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
