On Mon, Mar 10, 2003 at 09:11:06PM +0000, Keith Whitwell wrote:
José Fonseca wrote:
What disptach table would you be referring to, glapi or the TnL one? The
problem with disptach tables is that they completely break the OOP
concept as they work with regular functions instead of object methods.
That's a problem with the OOP concept, then. Techniques based around switching and updating dispatch tables are *the* way to do fast GL drivers.
My initial worry was that it's not safe (someone *please* correct me if I'm wrong) to put a C++ method in a C function callback, i.e., if you have:
struct function_table { ... void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor); ... } driver;
and
class Context { ... void BlendFunc(GLenum sfactor, GLenum dfactor); ... } ;
You can't simply do
driver.BlendFunc = Context::BlendFunc;
or can you?
No, because one of the things C++ does is pass around an extra parameter -- namely the 'self' pointer. The 'real' prototype looks something like:
void Context::BlendFunc( Context *self, GLenum sfactor, GLenum dfactor )
-- but there's no guarentee that this is actually what is happening, or that it won't change. Yes, I know there is an ABI now -- but I've no idea what it actually specifies. Does it allow the compiler to try & figure out if self is needed? If BlendFunc doesn't reference it, does it go away, or is it always passed even if its not needed?
Anyway, after I fully understood what you're proposing I realized this can be easily overcomed and even made easier with OOP + templates.
[snip]
This is great.
As I said above this can be done in C++, and without damage to efficiency.
Except that the functions plugged into the dispatch table cannot be C++ methods, as the prototypes are defined, and don't include the magic C++ self pointer.
I've deleted the rest of your explanation as unfortunately I don't think it can be made to work.
The principles of abstraction, inheritance etc are great, and can be used in efficient GL driver development, but at this level the calling convention is fixed and so the language might as well be C. You can do all the stuff you're talking about by selectively updating dispatch tables, either the top level one in libGL.so, or task-specific internal ones inside the driver.
This is something that C++ does internally, but for GL driver development you are probably better off doing it explicitly, as you have to at the libGL.so layer anyway.
And really, when you're doing the *real* critical code, such as the tnl modules, you definitely want to be doing runtime codegen anyway. Abstracting this between the drivers is certainly possible as big chunks of what we do there is machine independent.
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
