mesa3d-dev

[Mesa3d-dev] Modularization of software rasterizer

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

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.

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

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

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.

Keith

[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

[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

[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

Re: [Mesa3d-dev] Re: Modularization of software rasterizer

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

Brian Paul wrote:
> 
> 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.

I'm providing a RasterSetup stage to do this once per vertex buffer.  A
programmable vertex format is possible but complex.  I'm reluctant to do
anything like that unless translation turned out to be a bottleneck.  As I
said, the hardware drivers all do the same thing and the performance of those
drivers *is not* dominated by this stage.  

Keith

Re: [Mesa3d-dev] Re: Modularization of software rasterizer

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> > 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.
> 
> I'm providing a RasterSetup stage to do this once per vertex buffer.  A
> programmable vertex format is possible but complex.  I'm reluctant to do
> anything like that unless translation turned out to be a bottleneck.  As I
> said, the hardware drivers all do the same thing and the performance of those
> drivers *is not* dominated by this stage.

OK.  A little benchmarking will let us know if we have anything
to worry about.

-Brian