mesa3d-dev

Re: [Mesa3d-dev] Latest changes

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

Brian Paul wrote:
> 

> 
> Good work, Keith.  This is looking really good.
> 
> After compiling and taking a quick look over the code I just have a
> couple comments:
> 
> 1. _swsetup_RegisterVB() returns a boolean, but in dd.h, the RegisterVB
>    function pointer returns void.  Which should it be?

Hmm.  If it does fail (it alloc's memory, typically), I'm not sure we can go
on.  It might as well exit on failure and return void.

> 2. I think the SWvertex pointers passed to the point, line and triangle
>    functions could/should be const-qualified.  Right?

Probably, yes.

Keith

Re: [Mesa3d-dev] Latest changes

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

Keith Whitwell wrote:
> 
> I'll post a more detailed summary later, but I've committed changes with
> fairly sweeping scope.  Fundamentally, core mesa is out of the fallback
> business, this is now the job of the drivers and two helper modules 'swrast'
> and 'swrast_setup'.
> 
> Swrast is the old software rasterizer wrapped up behind an interface which
> removes the need for the driver to care about which statechanges might affect
> the rasterizer itself.
> 
> Swrast_setup is a layer above the software rasterizer which takes care of
> unfilled, offset, two-side lit and flatshaded primitives.  It also provides a
> RasterSetup phase for building SWvertices efficiently.
> 
> I've modified the FX, X11 and OSmesa drivers to this new regime, though at
> this point I've done nothing to ensure performance has been maintained.
> 
> In the case of the FX driver, I've taken steps to simplify the codebase in
> reflection of it's basically obsolete status.  To this end I've removed lots
> of marginal or experimental code, and backported some of the appropriate bits
> of a DRI style driver.  I propose that the focus of this driver be providing a
> solid Glide2 driver, and that if anyone wants to focus on performance and/or
> Glide3, they should backport the new tdfx-3-0-0-branch DRI driver, which
> offers very good performance gains on the Glide2 codebase.


Good work, Keith.  This is looking really good.

After compiling and taking a quick look over the code I just have a
couple comments:

1. _swsetup_RegisterVB() returns a boolean, but in dd.h, the RegisterVB
   function pointer returns void.  Which should it be?

2. I think the SWvertex pointers passed to the point, line and triangle
   functions could/should be const-qualified.  Right?

-Brian

[Mesa3d-dev] Latest changes

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

I'll post a more detailed summary later, but I've committed changes with
fairly sweeping scope.  Fundamentally, core mesa is out of the fallback
business, this is now the job of the drivers and two helper modules 'swrast'
and 'swrast_setup'.  

Swrast is the old software rasterizer wrapped up behind an interface which
removes the need for the driver to care about which statechanges might affect
the rasterizer itself.

Swrast_setup is a layer above the software rasterizer which takes care of
unfilled, offset, two-side lit and flatshaded primitives.  It also provides a
RasterSetup phase for building SWvertices efficiently.

I've modified the FX, X11 and OSmesa drivers to this new regime, though at
this point I've done nothing to ensure performance has been maintained.

In the case of the FX driver, I've taken steps to simplify the codebase in
reflection of it's basically obsolete status.  To this end I've removed lots
of marginal or experimental code, and backported some of the appropriate bits
of a DRI style driver.  I propose that the focus of this driver be providing a
solid Glide2 driver, and that if anyone wants to focus on performance and/or
Glide3, they should backport the new tdfx-3-0-0-branch DRI driver, which
offers very good performance gains on the Glide2 codebase.

Keith

Re: [Mesa3d-dev] compile informationals

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> Attached you find some indformationals I found when compiling the latest CVS
> version. Are there include files missing or is not yest everything moved to
> the swrast directory.
> 
>               Jouk
> 
> cc /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) COLORTAB.C
> 
>    gl_read_rgba_span( ctx, ctx->ReadBuffer, width, x, y, data );
> ...^
> %CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
> licitly declared as a function.
> at line number 635 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]CO
> LORTAB.C;1
> 
>    gl_read_rgba_span( ctx, ctx->ReadBuffer, width, x, y, data );
> ...^
> %CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
> licitly declared as a function.
> at line number 664 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]CO
> LORTAB.C;1
> 
> cc /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) /obj=[.x]xm_dd.
> obj [.x]xm_dd.c
> 
>       if (_mesa_clip_pixelrect(ctx, &dstX, &dstY, &w, &h, &srcX, &srcY)) {
> ..........^
> %CC-I-IMPLICITFUNC, In this statement, the identifier "_mesa_clip_pixelrect" is
> implicitly declared as a function.
> at line number 856 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC.X]
> XM_DD.C;1
> 
> 
> c /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) TEXIMAGE.C
> 
>       gl_read_rgba_span( ctx, ctx->ReadBuffer, width, x, y + i,
> ......^
> %CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
> licitly declared as a function.
> at line number 2646 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]T
> EXIMAGE.C;1
> 
> cc /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) CONVOLVE.C
> 
>    gl_read_rgba_span(ctx, ctx->ReadBuffer, width, x, y, (GLchan (*)[4]) rgba);
> ...^
> %CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
> licitly declared as a function.
> at line number 487 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]CO
> NVOLVE.C;1
> 
>       gl_read_rgba_span(ctx, ctx->ReadBuffer, width, x, y + i,
> ......^
> %CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
> licitly declared as a function.
> at line number 527 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]CO
> NVOLVE.C;1
> 

I'll clean these up shortly -- there'll be a public interface to this
functionality from the swrast module, I think.

Keith

[Mesa3d-dev] compile informationals

[<jo...@hr...>]

Hi all,

Attached you find some indformationals I found when compiling the latest CVS
version. Are there include files missing or is not yest everything moved to
the swrast directory.

              Jouk




cc /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) COLORTAB.C

   gl_read_rgba_span( ctx, ctx->ReadBuffer, width, x, y, data );
...^
%CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
licitly declared as a function.
at line number 635 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]CO
LORTAB.C;1

   gl_read_rgba_span( ctx, ctx->ReadBuffer, width, x, y, data );
...^
%CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
licitly declared as a function.
at line number 664 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]CO
LORTAB.C;1


cc /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) /obj=[.x]xm_dd.
obj [.x]xm_dd.c

      if (_mesa_clip_pixelrect(ctx, &dstX, &dstY, &w, &h, &srcX, &srcY)) {
..........^
%CC-I-IMPLICITFUNC, In this statement, the identifier "_mesa_clip_pixelrect" is
implicitly declared as a function.
at line number 856 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC.X]
XM_DD.C;1

 
c /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) TEXIMAGE.C

      gl_read_rgba_span( ctx, ctx->ReadBuffer, width, x, y + i,
......^
%CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
licitly declared as a function.
at line number 2646 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]T
EXIMAGE.C;1



cc /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) CONVOLVE.C

   gl_read_rgba_span(ctx, ctx->ReadBuffer, width, x, y, (GLchan (*)[4]) rgba);
...^
%CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
licitly declared as a function.
at line number 487 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]CO
NVOLVE.C;1

      gl_read_rgba_span(ctx, ctx->ReadBuffer, width, x, y + i,
......^
%CC-I-IMPLICITFUNC, In this statement, the identifier "gl_read_rgba_span" is imp
licitly declared as a function.
at line number 527 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001103.MESA.SRC]CO
NVOLVE.C;1



Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] Cannot compile Mesa 3.4 on Windows

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> No one has been maintaining the Windows support in Mesa for a
> while now.
> 
> If you can fix these problems let me know so I can apply patches.

Once I finish my new optimized path test harness (ie. an extension of
the functionality in debug_xform.c) I'm going to revisit this issue.  I
want to run the assembly code through the test harness with VTune, and
thus I'll have to get it to compile under MSVC.

-- Gareth

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

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

[Mesa3d-dev] Mesa 3.4 finalization

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

I'm putting the finishing touches on the Mesa 3.4 release.

I hope nobody has anything left to add.  If so, contact me
soon.

I just have to do some final testing on my home system tonight.
If all goes well, I'll release tomorrow.

-Brian

[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

[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,
> 
> 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

Re: [Mesa3d-dev] Cannot compile Mesa 3.4 on Windows

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

Ken-ichi Mori wrote:
> 
> Hello,
> 
> I'm trying to compile Mesa 3.4 and 3.5 on Windows using VC++ 6.0.
> The GL libs (OpenGL32.dll and mesa.lib) were compiled easily.
> But, The GLU libs were not compiled with errors.
> It seems to be ...
>         In "include/GL/mesa_wgl.h" ( included by "include/GL/gl.h" ),
>         HGLRC and HDC are used before they are defined.
> (I'm not sure because there are too many #ifdefs for a newcomer...)
> 
> Please help me. Thank you.


No one has been maintaining the Windows support in Mesa for a
while now.

If you can fix these problems let me know so I can apply patches.

-Brain

[Mesa3d-dev] Cannot compile Mesa 3.4 on Windows

[Ken-ichi M. <ken...@to...>]

Hello,

I'm trying to compile Mesa 3.4 and 3.5 on Windows using VC++ 6.0.
The GL libs (OpenGL32.dll and mesa.lib) were compiled easily.
But, The GLU libs were not compiled with errors.
It seems to be ...
	In "include/GL/mesa_wgl.h" ( included by "include/GL/gl.h" ),
	HGLRC and HDC are used before they are defined.
(I'm not sure because there are too many #ifdefs for a newcomer...)

Please help me. Thank you.

Moriken

[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] WinCVS anaymous login

[Tom \(N. Instruments\) <to...@na...>]

Hallo,

can anybody help me to get access via WinCVS? What are the needed paramters?
I had never worked before with that tool.

Thanks, Tom

[Mesa3d-dev] Software rasterizer moved

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

OK,

The bulk of the move is completed.  This means that commits can resume to the
trunk.

However, there has been very little testing of this change - it will be at
least a day or so before anybody should expect stability on the trunk.

Keith

[Mesa3d-dev] Please no commits to trunk for next 24 hours or so

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

I've got to do some rearrangement of code on the trunk (Mesa 3.5
development).  The effect will be to seperate the software rasterizer out from
the rest of the Mesa code and place it in it's own directory.  Later
development work will tighten up the interfaces between this code and the rest
of Mesa and it's drivers.

In the meantime, I've got to have a stable snapshot of mesa to work on, as CVS
doesn't cope well with merging over wholesale code relocation...  So, can I
ask people to hold off on committing to the trunk for the next day or so. 
I'll post another notification when the trunk has stabilized again.

Keith


PS.  If you do have something that needs to go in right away, drop me a note &
I'll see if I can accomodate you.

Re: [Mesa3d-dev] samples/sphere broken in last two weeks?

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

Gareth Hughes wrote:
> 
> Brian Paul wrote:
> >
> > Gareth Hughes wrote:
> > >
> > > One of the updates to the Mesa-3.4 codebase in the last two weeks seems
> > > to have broken texturing in this demo app.  Software rendering with
> > > standalone Mesa fails to texture the torus at all, and thus it's not
> > > surprising that the hardware drivers also fail to texture it.  I just
> > > updated with
> > >
> > > cvs update -D "2 weeks ago"
> > >
> > > which pulls in the code from directly before the tdfx branch changes
> > > were added.  I'll create a diff of what's changed in that period and try
> > > to track it down.
> >
> > I've checked in a bunch of changes to this demo. It seems to work
> > fine with software rendering in 3.5 but still isn't working with 3.4.
> >
> > The DRI tdfx-3-0-0 driver is having trouble with it too.
> 
> I'm not surprised, as the Mesa code on that branch should be what's in
> 3.4.  Should we just leave it as fixed in 3.5?  Should I even bother
> looking into it at the moment?

We should fix it in 3.4.  If you don't beat me to it, I'll look deeper
on Wednesday.

-Brian

Re: [Mesa3d-dev] samples/sphere broken in last two weeks?

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> Gareth Hughes wrote:
> >
> > One of the updates to the Mesa-3.4 codebase in the last two weeks seems
> > to have broken texturing in this demo app.  Software rendering with
> > standalone Mesa fails to texture the torus at all, and thus it's not
> > surprising that the hardware drivers also fail to texture it.  I just
> > updated with
> >
> > cvs update -D "2 weeks ago"
> >
> > which pulls in the code from directly before the tdfx branch changes
> > were added.  I'll create a diff of what's changed in that period and try
> > to track it down.
> 
> I've checked in a bunch of changes to this demo. It seems to work
> fine with software rendering in 3.5 but still isn't working with 3.4.
> 
> The DRI tdfx-3-0-0 driver is having trouble with it too.

I'm not surprised, as the Mesa code on that branch should be what's in
3.4.  Should we just leave it as fixed in 3.5?  Should I even bother
looking into it at the moment?

-- Gareth

[Mesa3d-dev] Re: [Mesa3d-cvs] 'Mesa/samples sphere.c'

[Gareth H. <ga...@va...>]

br...@us... wrote:
> 
> Update of /cvsroot/mesa3d/Mesa/samples
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv26568
> 
> Modified Files:
>         sphere.c
> Log Message:
> big overhaul of the demo, works better now

Application error then?

-- Gareth

Re: [Mesa3d-dev] samples/sphere broken in last two weeks?

[Gareth H. <ga...@va...>]

"Dieter Nützel" wrote:
> 
> which image file do you use for testing?
> I get mostly 'No image file.'
> Or this:
> 
> SunWave1>./sphere -f ../images/girl.rgb
> Invalid image format (must be `P6')

There's a file rgbtoppm.c in Mesa/samples - compile it up and run it on
the .rgb image files to create .ppm image files.  Not sure what the
command line options are, but it's pretty trivial to do.

Once you've got a bunch of .ppm images, all of the apps in Mesa/samples
should work.  They all require this different format.

-- Gareth

Re: [Mesa3d-dev] samples/sphere broken in last two weeks?

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

Gareth Hughes wrote:
> 
> One of the updates to the Mesa-3.4 codebase in the last two weeks seems
> to have broken texturing in this demo app.  Software rendering with
> standalone Mesa fails to texture the torus at all, and thus it's not
> surprising that the hardware drivers also fail to texture it.  I just
> updated with
> 
> cvs update -D "2 weeks ago"
> 
> which pulls in the code from directly before the tdfx branch changes
> were added.  I'll create a diff of what's changed in that period and try
> to track it down.

I've checked in a bunch of changes to this demo. It seems to work
fine with software rendering in 3.5 but still isn't working with 3.4.

The DRI tdfx-3-0-0 driver is having trouble with it too.

-Brian

Re: [Mesa3d-dev] Re: Callbacks/API hookouts vs. NEW_* flags

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

Brian Paul wrote:
> 

> > Rather than attempting to call callbacks for every piece of state in an
> > attribute, consider adding:
> >
> >         ctx->Driver.NotifyStateChange( GLcontext *ctx, GLuint newstate )
> >
> > or, for consistency:
> >
> >         ctx->Driver.Wakeup( GLcontext *ctx, GLuint newstate )
> 
> How are these functions different from ctx->Driver.UpdateState()?
> 
> Also, how is the newstate parameter different from ctx->NewState?

Differ in semantics:  UpdateState is called all the time, even when the
callbacks are called.  Wakeup would be called without the callbacks having
been called.  Thus we wouldn't have to call the callbacks from PopAttrib, for
instance.  

The flags in the parameter have the same meanings.

Keith

[Mesa3d-dev] Re: Callbacks/API hookouts vs. NEW_* flags

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

Keith Whitwell wrote:
> 
> Brian,
> 
> I've been thinking about this a little bit & it seems to me there will always
> be good reason to keep both of these state update mechanisms around.
> Additionally, by extending the use of the _NEW_ flags we can overcome a couple
> of uglinesses in the current code base.
> 
> We've talked about this before and I'd said that my position was roughly:
> 
>         - Callbacks (to be replaced/augmented by API hookouts) are the mechanism for
> keeping the hardware driver uptodate
>         - _NEW_ flags are used
>                 - to wake up things like the software rasterizer or t&l mechanism after
> being put to sleep
>                         - a large amount of state may have changed without any other notification
>                 - to keep those components uptodate during normal operation
>                         - this is the current gl_update_state mechanism, split up between core,
> rasterizer and t&l
> 
> The two uses for the _NEW_ flags can be handled by the same code -- the only
> difference is the amount of state that might have changed.
> 
> To this I'd like note another use for the _NEW_ flags:  to notify the driver
> itself after a very large state-change, when using callbacks would be
> cumbersome.  The obvious example of such a state-change is in glPopAttrib().

Good point.

I agree that having both _NEW* flags and callbacks is good.  It allows
the driver implementor some flexibility.


> Rather than attempting to call callbacks for every piece of state in an
> attribute, consider adding:
> 
>         ctx->Driver.NotifyStateChange( GLcontext *ctx, GLuint newstate )
> 
> or, for consistency:
> 
>         ctx->Driver.Wakeup( GLcontext *ctx, GLuint newstate )

How are these functions different from ctx->Driver.UpdateState()?

Also, how is the newstate parameter different from ctx->NewState?


> which can be called in these cases.  The driver would be expected to know
> enough about it's internal state to handle this event.


-Brian