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.
No, because different threads have different contexts and hence different dispatch tables. But the code I showed will always load the same one, no matter which thread calls it. It's a pain in the ass.
The same thing applies to getting the current context -- you have to get it from thread local storage, which historically has been dog slow. For codegen you can just hardcode the value into generated functions, but you don't want to generate *everything*, just stuff like Color3f, Vertex3f, etc. Doing this in a module that can be shared by drivers is entirely feasible. The standard tnl module on the vtx-0-1-branch does/will-do this.
> 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)
OK.
Keith
------------------------------------------------------- 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
