Some brief comments from an historical perspective... On Thu, Sep 16, 2010 at 09:46:49PM -0700, bugzilla-dae...@freedesktop.org wrote: | https://bugs.freedesktop.org/show_bug.cgi?id=30172 | | --- Comment #20 from Luca Barbieri <luca.barbi...@gmail.com> 2010-09-16 21:46:49 PDT --- | FWIW, here is how to design an extension system which is actually usable...
Designs like this were considered, but rejected for a number of reasons (some of which may no longer apply). Here are a few that I remember off the top of my head. 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. You also need to prevent compilers from caching the table pointer or individual entry pointers. 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? 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. Structs as part of the interface don't work well for all language bindings. 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. Allen _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
