Bob Beretta wrote: > > Hi All, > > Arguments *for* context-specific function pointers from glGetProcAddress: > (possibly MacOS specific, but maybe not...) > > 1) On the Macintosh, the link library (libGL.so equivalent) manages multiple > graphics devices with independent drivers in a way that is transparent to the > application. It does this by exporting a wrapper layer that may redirect the > OpenGL commands from one driver to another, or to multiple drivers > simultaneously, depending on the configuration of the screens and the > current location of the application window. In general, an application > may bypass the overhead of the wrapper layer by accessing the *real* GL > entry points that are stored in the context. What are the *real* entrypoints? Are these pointers to the actual driver functions? Or are they just another (less expensive) wrapper? I'm not very familiar with Apple/Conix's implementation. > When an app calls glGetProcAddress, what is really returned is a pointer > to a function that is generated at run-time - a wrapper for the real pointer(s) > returned from the driver. The problem is that two contexts may very well > be attached to two entirely different drivers, making the *real* proc pointer > for one context useless for another. Or, one context may be attached to a > single driver while the other is attached to multiple drivers, making the > wrapper function itself inappropriate for use with the wrong context. What happens when the user moves the window to a monitor controlled by another driver (or worse, the window spans two monitors)? Doesn't this present the same problem (suddenly the *real* function pointer isn't valid anymore)? > The only way I can see to code my way around this is to A) ignore the > wrapper function issue and accept the logic overhead of a generic wrapper > AND B) keep track of all calls to glGetProcAddress in the link library > and have the library internally extract all the previously requested function > pointers from each driver whenever a new context is created AND C) go > back and "fix up" all existing contexts with each new call to > glGetProcAddress so a procedure may be used with a context that was > created previously. What a pain! I don't see that it has to be _that_ difficult. If I were architecting the implementation, I'd have the drivers "register" all of their entrypoints with the link library at context creation time. If a particular driver registered an entrypoint that I hadn't seen before, I'd simply put it in the next available slot in the jump table. Contexts created previously could easily be updated at MakeCurrent time if necessary. > It seems to me that any X implementation for Linux that tries to tackle the > multi-screen problem in a generic way (like Conix/Apple did) will run into > similar difficulties, so I think it would be prudent to leave the per-context > pointers in the spec. Maybe I'm missing something, but I don't see that making the pointer context specific solves any of the problems you've brought up. As you've pointed out, the actual driver routine that needs to be called isn't just a function of which context is current. It always depends on the current pipeline state, but in a heterogeneous multi-headed environment, it also depends on the position of the rendering view (i.e. the device that's being rendered on can change dynamically as the window is moved). Multi-head OpenGL is already a tough problem, and making it heterogeneous, and transparent to the app is a **really-really** tough problem! If you guys can solve it in any fashion, context specific pointers or no, you have my respect and admiration! > 2) Further, one context may support the extension of which the function > pointer is a part and another context may not, making the pointer useless > for the second context. This is a good point. It does seem kind of funny for GetProcAddress to return a pointer that is callable, but does nothing. It's also a little fuzzy what GetProcAddress should return if it gets a request for a function that it the dispatcher hasn't seen before. My instinct is that it should go ahead and assign a dispatch table entry to the name and return a valid pointer, but maybe set some kind of glError. > glGetString may return different extension strings > for different contexts in a multiple-graphics-device environment, so it > follows semantically that glGetAnythingEXT must return context > specific information. This idea gets really weird in a heterogeneous environment like you're describing though, because even the results from glGetString can't be counted on to remain valid once the window is moved. If the user moves the window from a device which supports glWizBang3fvEXT, to a device that doesn't, what happens? The problems you've pointed out are certainly valid problems, and I'm not sure what the best way to solve them is. However, I don't see how specifying GetProcAddress to return context specific pointers will help with the solution. Cheers!
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
