Michael I Gold wrote: > > 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 I don't agree that it's a burden on driver code. In fact, I'd argue that it actually somewhat simplifies the driver, since the driver doesn't have to have its own custom dispatching mechanism any more. > 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? This problem is the whole point of the "Well defined dispatch API" I was talking about. The driver would only manage it's own dispatch table through this API. libGL would manage the allocation of table slots, context switching etc... This really isn't that hard of a problem, and I've already written the code to solve it. Should the need arise (i.e. we actually decide to define a dispatch layer like I'm proposing), I'm sure HP will not have a problem with my GPL'ing it. > 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. Actually, for the past 5 years I've been busy writing & tuning significant chunks of HP's OpenGL implementation (mostly on HP-UX, but some work on NT). In fact, strangely enough, one of the chunks I wrote is a zero-overhead dispatching mechanism for our HP-UX (and NT) OpenGL implementations that is rather strikingly similar to what I've been talking about here 8^). BHP (Before HP), I wrote 3d modeling & rendering application code for a company called Strata (StrataVision, StudioPro, anyone remember StrataVirtual?). So anyway, I've parked my butt on both sides of the fence. I'm actually looking at this from the driver side right now, since that's my job at HP, but I don't see any downsides for what I'm proposing on the application side either. > 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). I'm acutely aware of the effort required to maintain graphics drivers (we're currently maintaining HP-UX and NT OpenGL drivers, along with HP-UX Starbase drivers. I'm personally hoping that we'll also be maintaining Linux OpenGL drivers in the future. Believe me, I'm aware of the problem!). However, as I mentioned above, I believe that my proposal will simplify the driver, not make it more complex. > 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. Well, at least we agree on our dislike of the Windows platform ;oD... Cheers! BTW, I'm going to be gone till the middle of next week, so if I don't reply to a post right away, it's not 'cause I've lost interest!
begin:vcard n:Johnson;Brett x-mozilla-html:FALSE org:Hewlett-Packard;Worstation Systems Lab adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] title:WSL Turtle Master fn:Brett Johnson end:vcard
