[Mesa3d-dev] Re: Modularization of software rasterizer

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

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"?


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

I found years ago when I wrote the original VB code that compilers
could optimize loops over simple arrays better than loops over arrays
of structs.  With hand-written X86 code that's probably not an issue,
except perhaps for caching issues.

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



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



> All in all the effect is to make the software rasterizer look a lot more like
> the hardware rasterizers, or like glide - an abstraction layer above a
> hardware rasterizer.
> 
> I'm also providing some helper functions to build SWvertices from vertex
> buffer indices, and to help with special drivers like X11 that want to extend
> the software rasterizer.
> 
> This interface will be documented by a text file in the swrast directory.

Great!

-Brian