Jon Leech wrote: > > On Thu, Sep 09, 1999 at 05:42:47PM -0400, Brian Paul wrote: > > Michael I Gold wrote: > > > Technically, the same ptr should work for any compatible context, where I'd > > > define compatible as sharing the same Visual. > > > > I'm still not sure I see the reason for all this. [...] > > > > It seems to me that just as glClear() is able to jump into the proper > > context-dependant subroutine, so should glPolygonOffsetEXT() or any > > other extension function. [...] > One alternative would be to *require* all vendor extensions to > implement whatever libGL *would have* implemented were it updated to > directly support that extension, so that calling into the "A" pointer > gets redirected into the "B" driver. This seems technically challenging > and open to abuse. It's a pretty hefty dis-incentive for driver writers to use this interface as well... Yuck. > Another alternative is for glGetProcAddress to dynamically extend > the libGL dispatch tables, dynamically synthesize entry points which > dispatch through those tables, and return a pointer to the resulting > hunk of code (Brett suggested this a few posts ago). This seems > hideously complex, Well, it seems complex the way you've described it, but the actual implementation should be pretty simple (but platform specific). I'll address one way of implementing it below. > and I don't know if it's even necessarily possible on > all architectures supporting Linux (does everyone have writeable code > space these days?). The implementation doesn't necessarily need to use writeable code (the PA-RISC implementation doesn't for example). Let me phrase it this way: Some form of dynamic dispatching must exist on any platform that supports shared (or dynamically loaded) libraries. I would suggest that, for a given platform, we use the same mechanism that is used to resolve a shared library function call. Disclaimer: I'm not an IA32 expert, so I'm not 100% certain of everything I say in this next paragraph... It seems that a pretty common approach to this problem on the Intel platform is to create dynamic jump tables. If I'm not mistaken, this is how calls into shared libraries are resolved (i.e. The "call" instruction jumps to an entry in a linker-provided jump table, which originally points to a lookup routine. The lookup routine then finds the correct function, modifies the jump table entry to point to the "real" function, then calls the "real" function. Any calls after that will jump directly to the "real" function). I can see a similar (but much simpler) technique being used to provide dynamically updated function pointers. On other platforms, I would imagine that a similar (or much more elegant in the case of PA-RISC ;o) method for dynamic shared lib function symbol resolution exits. One reason that I keep beating on this concept is because I think it has much wider application than this one function. I believe that the same method should be used to provide a general purpose (and high performance) dynamic dispatching method for the whole OpenGL library. I implemented something similar to this for our OpenGL library on HP-UX (so that we could dynamically redirect OpenGL calls depending on the pipeline state of the current context), and it's worked quite well (even if I do say so myself ;o). By definition, this is a tractable problem for any platform that supports dynamically loadable libraries (and hence, for any platform that could conceivably support Linux). Therefore, I don't think we should hobble app developers with a problem that could be taken care of in the libGL implementation. Also, as I mentioned above, I think the solution to this problem is generally useful as a high performance dynamic dispatch solution for the entire libGL. > Of course the GLX dispatch table needs to be > extended on the server side as well, but that's a tractable task - > unrecognized GLX opcodes could be handed off to some standard entry > point in each driver. > > A third alternative is to somehow convince all suppliers of libGL to > keep up with every possible extension shipped with every hardware > driver, and make sure that whenever the end user installs a new driver, > she also installs an updated libGL which knows about all extensions in > that driver. This presents few technical difficulties but I don't think > it's practical *in the general case* (it might be with reference to some > specific libGL). I agree. This isn't practical. > Finally, ISVs could just restrict themselves to whatever entry > points happen to be in the libGL they're running under. This is a > copout, but might often happen - it imposes no additional burdens on > ISV, libGL supplier, or driver supplier. I don't think that this approach offers much incentive for graphics card vendors to use our ABI. I know that HP offers some vendor extensions that offer significant differentiation (occlusion culling comes to mind). We wouldn't have much incentive to provide drivers if they didn't provide some differentiation for our hardware. So I don't think this is practical either. 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
