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? Anyway, after I fully understood what you're proposing I realized this can be easily overcomed and even made easier with OOP + templates. > >What are the specific problems of the module swapping? > > The current mechanism tries to make it fast to swap *portions* of > a dispatch table. Better just to maintain two different tables & > switch between them. I see. > Of course, that doesn't mean that the tables are static -- > incremental updates of a dispatch table are a key mechanism to > managing GL statechanges (which is underutilized in the current > drivers). > > > > >>We could do OUTSIDE_BEGIN_END testing the same way for free. > > > > > >You lost me here... > > In the simplest example you'd have two dispatch tables -- one for > inside begin/end, one for outside. Switch between them in Begin > and End. The inside one has 'Error' stubs for all state > functions, and the tnl driver plugged in. The outside one has the > state functions (which no longer need to check for > OUTSIDE_BEGIN_END), and some special-case handlers for > Color,Vertex,etc. This is great. As I said above this can be done in C++, and without damage to efficiency. Imagine you have a TnL abstract class: class TNL { // A OpenGL function virtual void Coord3f(GLfloat x, GLfloat y, GLfloat z) = 0; // Activate virtual void activate() = 0; protected: struct dispatch_table *my_dispatch_table; } ; and then you have two inherited classes for software and hardware rendering: class SoftwareTNL : public TNL { // The software version. Note the _inline_ inline void Coord3f(x, y, z) { _mesa_swrast_deal_with_this_vertex(x, y, z); } }; class HardwareTNL : public TNL { // The hardware version. Note the _inline_ inline void Coord3f(x, y, z) { _add_vertex_to_DMA_buffer(x, y, z); } }; and then the C-callable versions for the glapi disptach table: void softwareCoord3f(GLcontext *ctx, GLfloat x, GLfloat y, GLfloat z) { Driver::Context *context = ctx; Driver::SoftwareTNL &tnl = ctx->tnl; // There will be no call as the function will be expanded inline tnl.Coord3F(x, y, z); } and the same for the hardware version... In the activate method we can either swap the dispatch table entirely, or update part of it: void SoftwareTNL::activate() { ... _glapi_set_table(softwareCoord3f); // or something similar } Note that we can even overload the operator= on TNL to automatically call "activate()". Templates will have to be use for the automatic generation of the C-callable versions. Then this would be mainly implementation details, which a driver wouldn't need to care for. Of course that I won't go in such depth now. These are efficiency details, but is good to know that we can address them later, without messing around with the design. José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------------------------------------------------------- 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