At 03:33 PM 9/16/99 -0600, you wrote:
>But Michael, I'm *not* adding another indirection. The whole point of all
>these posts I've been writing is that only *one* indirection needs to exist,
>and it might as well be at the libGL layer rather than at the driver layer.
>In fact, I'm *removing* one layer of indirection in the case of direct
>calls, and leaving pointer calls the same (both have only one indirection).
The tradeoff you make is a minor simplification of application code versus
a significant burden on driver code. While anything is possible (its just
code after all) consider the ramifications of your proposal on driver
dispatch management. Now the dispatch table lives in libGL.so and is
dynamic. If I want to modify the dispatch entry for an extension, where
does it go? In a slot provided by the driver? What if the user never
queries this entry point, where does it go then? Do I need to check every
extension dispatch entry point for NULL before I can update it in the driver?
While I'm not aware of your role at HP, I believe everyone else who is
pushing for context-independent function pointers is looking at it from the
application side. Sure, its easier for you if the implementation somehow
hides the dependencies. But looking at it from the driver side, it sounds
like a mess, a very large hairy mess, and will create OS-dependencies in
code which was previously clean and portable (I still have to maintain a
Windows driver, you see).
The Windows world has learned to manage this problem, and I do not believe
it is a significant burden for application developers. While my general
dislike of the Windows platform is a matter of public record, this is one
thing I think they got right.
