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
