Brett Johnson wrote:
|
| Allen, is your reply based on your having done it both ways, and measuring
| the difference? Or is it more of a hunch based on experience?
I didn't make the measurements myself, but I was around at the time
they were made. The reason the OpenGL sample implementation has
multiple levels of indirection for some commands is to reduce the cost
of updating the top-level dispatch table.
| ... We have found no measurable overall
| performance differences between the two for any reasonable dataset. ...
Obviously this depends a lot on the dataset, and I believe it depends
greatly on the underlying hardware, too. I'm inclined to vote for a
dispatch mechanism that can be optimized in the cases for which it's
worthwhile, even if the optimization is unnecessary for other
combinations of app and hardware.
| > Perhaps more importantly, some existing driver code defines the
| > dispatch table as a struct, so converting it to a dynamically-indexed
| > array of some kind means wholesale source code changes.
|
| This is a good argument if our objective is to be as compatible with
| existing Windows ICDs as possible, but I thought that was specifically not
| an objective. If it is an objective, why are we even discussing context
| independent GetProcAddress?
One high-level objective is to get many robust high-performance
implementations of OpenGL running on Linux as soon as possible.
Avoiding gratuitous differences between Linux drivers and existing
drivers helps, even if complete compatibility with Windows ICDs is not
a requirement. Not only does it improve the chance that code can be
shared (subject to the usual licensing restrictions), but it means
that driver developers don't have to spend some of their limited time
forking a new code base and then keeping the two code bases in sync.
Allen
