On Mon, Mar 10, 2003 at 11:08:23PM +0000, José Fonseca wrote:
> But the function I put in the table _was_ an ordinary function, and > not a C++ method, and no redirection call would take place with > inlining. That was the point of the explanation...
Uhm... how do you inline a function call that's going over a function pointer? Specifically, ask youself what's involved in inlining a function.
> And yes, I do believe that, with care, C++ won't create a noticeable > overhead, but there's no point to discuss it, as we can simply > benchmark it on the end.
There's probably a way to make this fly, but the way you have shown until now isn't it. You could for example have a dispatch _object_, that is, you end up calling:
dispatch->BlendFunc(...);
and you can switch the dispatch object. You are still calling the method thru a pointer. You could probably fix that with some clever use of function templates but I don't have a clear picture how software fallbacks could (efficiently) work in that case.
libGL.so provides a dispatch table that can be efficiently switched. 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:
00041930 <glBlendFunc>: 41930: a1 00 00 00 00 mov 0x0,%eax 41935: ff a0 c4 03 00 00 jmp *0x3c4(%eax)
unfortunately, that version isn't threadsafe, but Gareth is relentlessly persuing an efficient threadsafe equivalent.
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.
At lower level, you might need to virtualize again. Currently mesa and the drivers handle that with C function pointers, but classes with virtual methods could be substituted.
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
