[Mesa3d-dev] Re: Modularization of software rasterizer

[Brian P. <br...@va...>]

Keith Whitwell wrote:
> 
> 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)

OK, now that I see the "ValidateTriangle" function below I see what
you're doing.


> 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...

I am concerned about the performance hit of vertex translation.
There are some people still using software rendering who are
concerned about performance.  In one instance, people are running
the off-screen renderer on large parallel machines and using
composition to generate complex images. They'd likely notice a
performance hit if there were one.

I'll have to think about this more.

Have you considered adopting Glide's "programmable" vertex format
idea?  That is, we specify at runtime the offsets into the vertex
struct for XYZW, colors, texcoords, etc.


> > >         - 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;

I like this!  Pretty clever.  It never occured to me.


> 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...

-Brian