On Tue, Mar 11, 2003 at 12:27:40AM +0000, Keith Whitwell wrote: > libGL.so provides a dispatch table that can be efficiently switched.
Yep, I've read how that's implemented in Mesa. It's really nice once you figure out what's going on (the code of course looks a look more terrifying than your explaination). I was confused about José's intention (probably because I read the files he mentioned). In fact, after reading the rest of you mail, I'm still confused... I think... > The real 'gl' entrypoints basically just look up an offset in this > table and jump to it. No new arguments, no new stack frame, nada -- > just an extremely efficient jump. Note that this is the library > entrypoint, so we can't ask the caller to use a function pointer > instead: yes, that's nice and I agree that it should be reused wherever possible. > unfortunately, that version isn't threadsafe, but Gareth is > relentlessly persuing an efficient threadsafe equivalent. because there's nothing preventing one thread from writing over the same memory that another thread is accessing? I fail to see how that relates to the way the functions are called. > Given that this mechanism is in place already, it makes sense to use > it. Which also means that there isn't much need for virtual methods > in deciding which version of BlendFunc (or more relevantly, Vertex3f) > to use -- you've already got a virtualization mechanism right here. Sure. Haha! Now I really understand what you meant before by updating the dispatch tables. (Previously I just thought I had understood it, I was left wondering why it was so special) Marcelo ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
