[Mesa3d-dev] Re: Modularization of software rasterizer

[Keith W. <ke...@va...>]

Brian Paul wrote:
> 
> Keith Whitwell wrote:
> >
> > Brian,
> >
> > I'm currently tightening up the interfaces between the software rasterizer and
> > the rest of the world.
> >
> > Specifically this involves:
> >
> >         - a _swrast_InvalidateState( ctx, new_state ) routine, which must be called
> > with state updates to allow swrast to maintain an internal state.
> 
> Shouldn't that be "ValidateState"?

It depends how you look at it:
	- it tells the module to invalidate it's internal state. (lazy)
	- it tells the module to (re) validate it's internal state. (eager)

I like the lazy view & it corresponds with what's actually going on in the
code.


> >         - a SWvertex structure:
> >
> >         typedef struct {
> >            GLfloat win[4];
> >            GLfloat eye[4];              /* for GL_EXT_point_param only */
> >            GLfloat texcoord[MAX_TEXTURE_UNITS][4];
> >            GLchan color[4];
> >            GLchan specular[4];
> >            GLfloat fog;
> >            GLuint index;
> >            GLuint flags;
> >         } SWvertex;
> >
> >         All software primitive rasterization functions will expect such a vertex
> > instead of grabbing the values out of the VB directly.  This has a lot of
> > subtle benefits, including being able to call the software rasterizer from a
> > hardware driver (after translating hardware vertices to software ones), and
> > being able to call the software rasterizer from non-standard geometry
> > pipelines, like the fastpath.
> 
> So the VB will now be an array of structs instead of a struct of arrays?
> I'm fine with that as long as there isn't a performance hit in
> processing these vertex structs.

No, the VB is unchanged.  The software rasterizer no longer knows anything
about the VB, but specifies its own vertex format (like glide2 did).  There is
a need for translation between the two, just like with hardware rasterizers. 
I figure if we can do this fast enough to keep a hardware rasterizer busy it
shouldn't be a big overhead in a software rasterizer...

This makes the software rasterizer a lot more useful as a fallback path for
hardware drivers, as SWvertices can be built on the fly - from normal VB
structs, from hardware vertices, or from something new like a fastpath vertex.

This also means that the software rasterizer is a lot more self-contained and
can evolve independently from the vertex-buffer/t&l code.  

> In any case, I can see this as a positive improvement in overall design.

I hope that's still the case after my explainations above...

> >         - A set of entry points:
> >
> >                 _swrast_Quad
> >                 _swrast_Triangle
> >                 _swrast_Line
> >                 _swrast_Point
> >
> >         which can be called at any time and will always call the correct
> > quad/tri/line/point for the current state.  These feel a lot like
> > grDrawTriangle, etc.
> 
> Right.
> 
> Another thing that might be nice is to change gl_set_triangle_function()
> to return a triangle function pointer instead of stuffing it into
> ctx->Driver.TriangleFunc.
> 
> Once upon a time, Mesa's device driver interface didn't have TriangleFunc,
> LineFunc, etc pointers but instead a function which core Mesa called that
> returned a pointer to the driver's triangle function.
> 
> Does any of that sound appealing?

That is a possible next step to investigate.  I think this design is closer to
'multiple levels of dispatch' within Mesa and the driver, a term I've heard
thrown about once or twice...  These are entry points subject to dispatch at
the interface of the module.  When the module receives a state-change, it
doesn't revalidate the state there and then, but hook out the Line, Point, etc
functions to point to 'revalidate' stubs.

The static entry point:

void
_swrast_Line( GLcontext *ctx, SWvertex *v0, SWvertex *v1 )
{
   SWRAST_CONTEXT(ctx)->Line( ctx, v0, v1 );
}


The 'revalidate' stub:

static void
_swrast_validate_line( GLcontext *ctx, SWvertex *v0, SWvertex *v1 )
{
   SWcontext *swrast = SWRAST_CONTEXT(ctx);

   _swrast_validate_derived( ctx );
   _swrast_choose_line( ctx );

   swrast->Line( ctx, v0, v1 );
}


A snippet from '_swrast_invalidate_state()':

   if (new_state & _SWRAST_NEW_LINE)
      swrast->Line = _swrast_validate_line;


This way nobody needs to know anything about how swrast chooses it's
line/tri/point functions.  I believe Glide does something similar.  The
dispatch could probably be speeded up with similar techniques to the current
GL dispatch mechanism.  That's a future task...

Keith