Re: [Mesa3d-dev] Latest changes

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> > I'm looking at the swrast line functions.  There's no longer a third
> > provoking vertex parameter like there used to be.  For flat-shaded
> > lines it looks like your temporarily changing the 0th vertex's color,
> > calling the line function, then restoring the 0th vertex color.
> >
> > Why not declare a temporary vertex in the line template function,
> > set its color/specular/index fields to the provoking vertex's color
> > and pass it as a third vertex?
> 
> I chose this technique because it is a good match for hardware rasterizers we
> already understand.  The copy/restore has proven to be a fast operation on
> hardware drivers so I opted for uniformity.
> 
> The software setup code has more copying than the hardware code for 2 reasons:
> 
>         - most hardware code doesn't copy specular.  It should do if the hardware
> supports it & therefore we have some bugs in the hardware code (mga, i810,
> r128).
> 
>         - no hardware drivers support color-index rendering.
> 
> > I see you do something similar for triangles and for two-sided lighting.
> >
> > Here's an idea:
> >
> > Suppose in the SWvertex struct we declare color, specular, and index
> > to be 2-D arrays where the first dimension is the front/back-side
> > index:
> >
> >    GLchan color[2][4];  /* color[0] = front, color[1] = back */
> 
> I guess it's just a question of where the complexity goes.  I'm pretty happy
> with the current breakdown, of a simple triangle rasterizer that just knows
> about rasterizing triangles and is a good match for existing hardware
> rasterizers.  Above that, a layer which understands the parts of GL state that
> go beyond straightforward rasterization.
> 
> I don't think hardware rasterizers are going to change significantly, or at
> least not so that we can see - this is probably the last generation of cards
> where we'll have to talk to the rasterizer directly.
> 
> > Then we could pass a front/back flag to the triangle function to
> > tell it which color to use.
> >
> > Passing a front/back flag might also be useful for culling.
> 
> If you are going to pass anything it should be area, so that doesn't need
> recalculation.
> 
>         _swrast_Triangle( GLcontext *ctx,
>                           SWvertex *v0, SWvertex *v1, SWvertex *v2,
>                           SWvertex *pv,
>                           GLfloat area )
> 
>         _swrast_Line( GLcontext *ctx,
>                       SWvertex *v0, SWvertex *v1,
>                       SWvertex *pv,
>                       GLfloat area  or GLuint side )
> 
>         _swrast_Point( GLcontext *ctx,
>                        SWvertex *v0,
>                        SWvertex *pv,   /* need this for unfilled, flat-shaded tris */
>                        GLfloat area or GLuint side )
> 
> This helps to cut out the copying of data, but it's less obvious whats going
> on.  Hardware drivers should still be able to use this for fallbacks as long
> as the rasterizer is no smarter than the ones we've already seen.  In
> 'fx_fallback_line', you don't have access to the information to calculate
> area, but you can just pretend that the line is frontfacing, and fill in the
> color[0] values from the hardware vertices.

Your initial perf numbers seem to confirm that the hit isn't too big.
We can probably optimize things later to make up for any loss, if needed.

 
> Coincidentally, how does current mesa handle GL_POINT mode unfilled,
> flatshaded triangles?  How is the provoking vertex passed to the point
> routines?

It's not.  It's broken.  I guess no one's ever noticed.


> In any case I don't get as good a feeling when I look at these routines as I
> do when I look at the current ones.  As a stopgap, it is possible to split the
> color-copying code to copy either just rgba or (rgba, spec, index) depending
> on rendermode, etc.
> 
> As a general summary of my feelings, I guess I'd like to wait & see & find out
> more about this code before changing it in new directions...
> 
> > Could you put some comments in the swsetup triangle template about
> > the edge flag code?  I'm wondering what the 0x1 and 0x2 bits are
> > for and why they're being modified during rendering.  It seems to
> > me that the vertex buffer should not be modified during rasterization.
> 
> There are some old comments in vbrender.c about this.  I'm not entirely happy
> with the way I'm doing edgeflags yet -- the SI makes it look really simple by
> comparison.

OK.


How or where should we check for feedback and selection mode in
the point/line/triangle selection functions?  Should we test for
that down in the driver's code, or higher up in the _swrast_validate_point()
function?

-Brian