Pardon me for hammering on this just a little longer. Since the point
of the Linux OpenGL Base effort is to define what's needed for binary
compatibility, and the choice of implementation method for function
pointers affects that (as well as performance), we do need to be
careful about the issue.
Brett Johnson wrote:
|
| ... I don't like the idea of the
| driver owning and managing the actual dispatch table memory. I'd rather
| see the libGL manage the table memory and assign slots etc.., and have the
| driver manage the appropriate table entries through a more abstract API.
This does solve the problem of dispatching to drivers with different
capabilities, and it has some potential to make the dispatch code
faster (e.g, by using dynamically-generated jumps rather than indirect
jumps, as Brett suggested later in his message).
On the downside, it makes it more difficult to share code between
Windows and Linux drivers (as Michael mentioned), and it makes
state-change operations more expensive (instead of simply updating a
pointer in a table, or switching to a new table altogether, drivers
must call a private function in libGL).
I'd also argue that the potential performance benefit is likely to be
marginal on modern machines, which feature speculative execution and
branch target buffers. The CPU will execute indirect jumps
speculatively, and so long as the function pointer hasn't changed, the
total execution time isn't likely to differ much from the case of
dynamically-generated jumps. (And you don't have to worry about
flushing parts of the I-cache, either.) So I'm not convinced that
anything more sophisticated than a simple indirect jump is really a
win overall.
Allen
