Rik Faith wrote:
>
> Precision Insight released the first version of the Direct Rendering
> Infrastructure (DRI) to XFree86 in June 1999 (this version is currently
> available in the XFree86 3.9.15 snapshot). Since that time, we have been
> thinking about how to enhance and improve the DRI to better support more
> features and a wider range of graphics hardware. The first draft of a
> brief summary of our thoughts is now available for comment:
>
> http://precisioninsight.com/dr/dri2.html
> http://precisioninsight.com/dr/dri2.ps
> http://precisioninsight.com/dr/dri2.txt
>
> Before we complete a final draft in late August, we'd like to obtain
> impressions, feedback, and suggestions from the XFree86 and Mesa
> communities.
Below are my comments on some of the Mesa-specific issues.
-Brian
Comments on PI's "Extensions to the Direct Rendering Infrastructure"
dated "August 1999 DRAFT"
Brian Paul ([EMAIL PROTECTED])
----------------------------------------------------------------------
5.2 Miscellaneous Mesa Enhancements
Multiple Contexts
Mesa already handles multiple rendering contexts. See below for
a discussion about simultaneous direct and indirect contexts.
5.4 State Change Management
The Mesa device driver struct is slowly being expanded to include API
shadow functions. For example, the dd_function_table's AlphaFunc
function pointer shadows the glAlphaFunc() API function. Inside
the gl_AlphaFunc() we call ctx->DD.AlphaFunc if it's non-null.
Many more shadow functions are needed but can be easily implemented.
Note that the device driver's shadow API functions are called after
core Mesa performs error checking. This guarantees that the shadow
function will not be called with invalid parameters or at erroneous
times (i.e. inside glBegin/glEnd).
If a particular driver would rather do error checking itself it can
always patch into the top-level API dispatch table instead of the
driver shadow function.
When discussing GL state we have to keep in mind the glPushAttrib()
and glPopAttrib() functions. glPushAttrib() has to make a copy of
current state. If state cannot be queried from the hardware it will
have to be mirrored in Mesa's gl_context struct. glPopAttrib() calls
the driver API shadow functions in order to reapply state values.
5.5 Eliminating Indirection
Every Mesa API function _should_ go through an API function dispatch
table. Currently, some of the glVertex, glNormal, glTexCoord, etc
commands don't do this, instead storing their arguments in a vertex
buffer structure.
Making these function use the API dispatch table is a simple change.
Keith or I can do it. I believe that the small inefficiency introduced
by the extra indirection is acceptable for the time being. Optimization
is to come after correct implementation.
More on indirection, direct/indirect rendering
Note that an OpenGL application may have both direct and indirect
rendering contexts. That is, a call to a function like glClear()
may either directly issue a hardware command or encode a GLX message.
For the indirect case, a call to Mesa's glClear() should result in
the GLX encoder's glClear() function being called.
I just reviewed the GLX source and see that the GLX encoder functions
are named identically to the OpenGL API functions. This seems to be
a problem. We can't have both Mesa and the GLX encoder define a glClear
function, can we?
Perhaps we'll have to rename all of the API entry points in the GLX
code (g_render.c). I'd suggest a new prefix so that glClear() becomes
glxClear() or glx_Clear(). Accomodating both the original "gl" prefix
and "glx" prefix could be done with a C preprocessor macro.
Furthermore, in order to make the GLX encoder functions type-compatible
with Mesa's structure, we'll have to add a GLcontext parameter to each
function as its first argument. Using the glClear case again, the new
GLX encode function would look like this:
void glxClear( GLcontext *ctx, GLbitfield mask )
Here's a complete pseudo-code example of what I'm proposing.
Mesa's glClear function is this:
void glClear( GLbitfield mask )
{
GLcontext *CC = gl_get_current_context(); // or CC is a global var
(*CC->API.Clear)( CC, mask ); // jump through dispatch table
}
When an indirect GLX context is created, the Mesa context's dispatch
table is loaded with pointers to the GLX encoder functions:
GLXContext glXCreateContext( Display *dpy, XVisualInfo *vis,
GLXContext shareList, Bool direct )
{
...
GLcontext *ctx = gl_create_context(...); // create core Mesa context
// put GLX encoder functions into Mesa's API function table.
ctx->API.Accum = glxAccum;
...
ctx->API.Clear = glxClear;
...
ctx->API.Viewport = glxViewport;
...
return c;
}
The glxClear function would be:
void glxClear( GLcontext *ctx, GLbitfield mask )
{
__GLX_DECLARE_VARIABLES();
__GLX_LOAD_VARIABLES();
__GLX_BEGIN(X_GLrop_Clear,8);
__GLX_PUT_LONG(4,mask);
__GLX_END(8);
}
When a direct GLX context is created, the normal Mesa initialization
code will hook the GL execution and compilation functions into the
appropriate dispatch tables:
void mesa_pseudo_initialization_function()
{
// hook in immediate mode execution functions
ctx->Exec.Accum = gl_Accum;
...
ctx->Exec.Clear = gl_Clear;
...
ctx->Exec.Viewport = gl_Viewport;
// hook in display list compilation functions
ctx->Save.Accum = save_Accum;
...
ctx->Save.Clear = save_Clear;
...
ctx->Save.Viewport = save_Viewport;
// Later, Mesa will copy either the ctx->Save pointers or ctx->Exec
// pointers over the ctx->API pointers table depending if we're
// entering display list compile mode or immediate execution mode.
}
