mesa3d-dev

Re: [Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> > CVSROOT:        /cvsroot/mesa3d
> > Module name:    Mesa
> > Repository:     Mesa/src/
> > Changes by:     brianp@usw-pr-cvs1.     01/05/03 16:55:38
> >
> > Log message:
> >   do FLUSH_VERTICES() in glGet*() functions to make occlusion testing work, perhaps needed for other cases, like GL_CURRENT_COLOR
> >
> > Modified files:
> >       Mesa/src/:
> >         get.c
> >
> >   Revision      Changes    Path
> >   1.59          +21 -1     Mesa/src/get.c
> 
> In fact, for current color you need to issue a 'FLUSH_CURRENT()'.  I'll fix
> this.

Actually it's already there...

Keith

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

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

Brian Paul wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/src/
> Changes by:     brianp@usw-pr-cvs1.     01/05/03 16:55:38
> 
> Log message:
>   do FLUSH_VERTICES() in glGet*() functions to make occlusion testing work, perhaps needed for other cases, like GL_CURRENT_COLOR
> 
> Modified files:
>       Mesa/src/:
>         get.c
> 
>   Revision      Changes    Path
>   1.59          +21 -1     Mesa/src/get.c

In fact, for current color you need to issue a 'FLUSH_CURRENT()'.  I'll fix
this.

Keith

Re: [Mesa3d-dev] Hierachical Display List

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

Allen Barnett wrote:
> 
> Hi (yet again),
> 
> (Thanks Keith and Brian for your earlier responses.)
> 
> So, here is my problem code reduced to a simple GLUT program. Basically,
> I'm creating two display lists which contain only the geometry of a
> polygon, one to display the edge and the other for the filled interior.
> I then create another display list which sets an edge color, calls the
> display list for the edge, sets an interior color and calls the display
> list for the filled polygon. The redraw function just calls the combined
> display list.
> 
> This works OK with XFree86 DRI using the TDFX driver and with XFree86
> with LIBGL_ALWAYS_INDIRECT set; you get a blue triangle with a red edge.
> With the latest CVS version of Mesa, however, when the window is opened
> you only see a white triangle. Causing a refresh in the window yields a
> blue triangle but with no red edge (but I think it's drawing the edge in
> blue). [This is using the KDE window manager, if that matters.]

I'm seeing the same thing here (using FVWM).  Looks like a display
list bug because if I directly call the two sublists instead of the
parent list everything looks OK.

I think this is in Keith's department.


> I also see a little empty space between the diagonal edge of the filled
> polygon and its edge when using either version of the software rendering
> (indirect DRI or Mesa). I've tweaked PolygonOffset several ways, but
> can't see to make it go away.

Polygon offset won't help that.  It's the nature of triangle and line
rasterization to hit different pixels.  If you were to translate the
triangle and outline around the screen you'd see jitter between them.

Putting a perfect outline around a polygon is actually a hard problem.
Have you tried drawing a wider line?

-Brian

Re: [Mesa3d-dev] problems with current CVS

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> On My OpenVMS system I see the following prblems when testing Mesa3d from
> the CVS with the xlockmore program (get the latest beta version from:
> ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/ )
> 
>       -version from 27 April 2001 gives no problems at all
>       -version from 1 May and 3 May give problems (new tnl routines????):
>           -glplanet crashes due to access violation
>              (is everything allocated????)

It seems OK here.  Does it crash immediately or after it's been running
for a while?

>           -moebius does not display anything and seems to be in an infinite
>             loop.

Same thing here.  Keith's on another project for a few days.  I'll
see what I can do.

-Brian

[Mesa3d-dev] problems with current CVS

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

Hi all,

On My OpenVMS system I see the following prblems when testing Mesa3d from
the CVS with the xlockmore program (get the latest beta version from:
ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/ )

      -version from 27 April 2001 gives no problems at all
      -version from 1 May and 3 May give problems (new tnl routines????):
          -glplanet crashes due to access violation
	     (is everything allocated????)
	  -moebius does not display anything and seems to be in an infinite
	    loop.
	    
 Can others reproduce this on other systems?
	    
	  Jouk


Bush : All votes are equal but some votes are more equal than others.

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

  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

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

[Mesa3d-dev] Hierachical Display List

[Allen B. <ba...@lo...>]

Hi (yet again),

(Thanks Keith and Brian for your earlier responses.)

So, here is my problem code reduced to a simple GLUT program. Basically,
I'm creating two display lists which contain only the geometry of a
polygon, one to display the edge and the other for the filled interior.
I then create another display list which sets an edge color, calls the
display list for the edge, sets an interior color and calls the display
list for the filled polygon. The redraw function just calls the combined
display list.

This works OK with XFree86 DRI using the TDFX driver and with XFree86
with LIBGL_ALWAYS_INDIRECT set; you get a blue triangle with a red edge.
With the latest CVS version of Mesa, however, when the window is opened
you only see a white triangle. Causing a refresh in the window yields a
blue triangle but with no red edge (but I think it's drawing the edge in
blue). [This is using the KDE window manager, if that matters.]

I also see a little empty space between the diagonal edge of the filled
polygon and its edge when using either version of the software rendering
(indirect DRI or Mesa). I've tweaked PolygonOffset several ways, but
can't see to make it go away.

I await to be corrected :-)

Thanks,
Allen
--------------------------------------------------------------------------
#include <GL/glut.h>

GLuint edge_list;
GLuint solid_list;
GLuint display_list;

void init ( void )
{
  edge_list = glGenLists( 1 );
  solid_list = glGenLists( 1 );
  display_list = glGenLists( 1 );

  glEnable( GL_POLYGON_OFFSET_FILL );
  glEnable( GL_DEPTH_TEST );

  glNewList( edge_list, GL_COMPILE );
  glPolygonMode( GL_FRONT_AND_BACK, GL_LINE );
  glBegin( GL_POLYGON );
  glVertex3f( 0., 0., 0. );
  glVertex3f( 1., 0., 0. );
  glVertex3f( 0., 1., 0. );
  glEnd();
  glEndList();

  glNewList( solid_list, GL_COMPILE );
  glPolygonOffset( 1., 1. );
  glPolygonMode( GL_FRONT_AND_BACK, GL_FILL );
  glBegin( GL_POLYGON );
  glVertex3f( 0., 0., 0. );
  glVertex3f( 1., 0., 0. );
  glVertex3f( 0., 1., 0. );
  glEnd();
  glEndList();

  glNewList( display_list, GL_COMPILE );
  glColor3ub( 255, 0, 0 );
  glCallList( edge_list );
  glColor3ub( 0, 0, 255 );
  glCallList( solid_list );
  glEndList();
}

void display ( void )
{
  glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
  glCallList( display_list );
  glutSwapBuffers();
}

int main ( int argc, char* argv[] )
{
  glutInit( &argc, argv );
  glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH );
  glutInitWindowSize( 300, 300 );
  glutCreateWindow( argv[0] );
  init();
  glutDisplayFunc( display );
  glutMainLoop();
  return 0;
}

Re: [Mesa3d-dev] MESA_trace Facility

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

Allen Barnett wrote:
> 
> Hi (again),
> 
> I was trying out the Mesa Trace facility. The spec file in the docs
> directory says that it should produce 'logs [which] are valid (but
> possibly incomplete) C code'. I took a stab at:
> 
> glNewTraceMESA( TRACE_OPERATIONS_BIT_MESA, "log" );
> glEnableTraceMESA( TRACE_OPERATIONS_BIT_MESA );
> // draw, draw, draw
> glEndTraceMESA();
> 
> which produced a file named "log-gl.log.0". However, the contents of the
> file are evidently binary. Are there other calls I need to make to get a
> text file? Or is there a post-processor for this output?

The trace facility was never really finished.  The code was donated
by a couple guys at Loki games but it never got polished.  Feel
free to poke around and fix it if you're so inclined.

-Brian

[Mesa3d-dev] MESA_trace Facility

[Allen B. <ba...@lo...>]

Hi (again),

I was trying out the Mesa Trace facility. The spec file in the docs
directory says that it should produce 'logs [which] are valid (but
possibly incomplete) C code'. I took a stab at:

glNewTraceMESA( TRACE_OPERATIONS_BIT_MESA, "log" );
glEnableTraceMESA( TRACE_OPERATIONS_BIT_MESA );
// draw, draw, draw
glEndTraceMESA();

which produced a file named "log-gl.log.0". However, the contents of the
file are evidently binary. Are there other calls I need to make to get a
text file? Or is there a post-processor for this output?

Thanks,
Allen

Re: [Mesa3d-dev] Calling glGetError during glBegin/End

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

Allen Barnett wrote:
> 
> Hi,
> 
> While trying to diagnose a rendering problem with my code, I added a
> call to glGetError after each glVertex call between glBegin and glEnd.
> With Mesa compiled with debugging turned on, _mesa_error was reporting
> INVALID OPERATION to stdout even though glGetError itself returned 0.
> According to the man page, this is the correct result but it also
> mentions that there should be no other side effects. However, when
> calling glGetError, the FLUSH_VERTICES macro is invoked by the
> ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL macro at the beginning of
> _mesa_GetError. This seems to have a (negative) effect on the display
> list which is being constructed.
> 


This is a trap; glGetError is *not* allowed between Begin/End pairs, and is
required to generate the error you are seeing.

Keith

[Mesa3d-dev] Calling glGetError during glBegin/End

[Allen B. <ba...@lo...>]

Hi,

While trying to diagnose a rendering problem with my code, I added a
call to glGetError after each glVertex call between glBegin and glEnd.
With Mesa compiled with debugging turned on, _mesa_error was reporting
INVALID OPERATION to stdout even though glGetError itself returned 0.
According to the man page, this is the correct result but it also
mentions that there should be no other side effects. However, when
calling glGetError, the FLUSH_VERTICES macro is invoked by the
ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL macro at the beginning of
_mesa_GetError. This seems to have a (negative) effect on the display
list which is being constructed.

I activated the _tnl_print_cassette function in _tnl_compile_cassette.
WITHOUT calling glGetError between glBegin/End, after all three vertices
have been defined, _tnl_print_cassette produces:

Cassette id 0, 3 rows.
Contains at least one: (0x880001) eye/glbegin, obj, obj-3,
Contains a full complement of: (0x80001) obj, obj-3,
Final begin/end state out/out, errors y/n
3: Obj 0.000000 0.000000 0.000000 1.000000 BEGIN(GL_POLYGON)
(BEGIN,END,)
4: Obj 10.000000 0.000000 0.000000 1.000000
5: Obj 0.000000 10.000000 0.000000 1.000000
6:  END

which seems reasonable. If I call glGetError after each glVertex, then I
get three separate invocations of _tnl_compile_cassette after each
vertex is defined:

Cassette id 0, 1 rows.
Contains at least one: (0x880001) eye/glbegin, obj, obj-3,
Contains a full complement of: (0x880001) eye/glbegin, obj, obj-3,
Final begin/end state in/in, errors y/n
3: Obj 0.000000 0.000000 0.000000 1.000000 BEGIN(GL_POLYGON)
(LAST,BEGIN,)
4:
............ some output deleted ..........
Cassette id 0, 1 rows.
Contains at least one: (0x80001) obj, obj-3,
Contains a full complement of: (0x80001) obj, obj-3,
Final begin/end state in/in, errors n/n
8: Obj 10.000000 0.000000 0.000000 1.000000
9:
............ some output deleted ...........
Cassette id 0, 1 rows.
Contains at least one: (0x80001) obj, obj-3,
Contains a full complement of: (0x80001) obj, obj-3,
Final begin/end state in/in, errors n/n
13: Obj 0.000000 10.000000 0.000000 1.000000
14:
............ some output deleted ...........
Cassette id 0, 0 rows.
Contains at least one: (0x0)
18:  END

When I draw this display list later, I get a torrent of INVALID
OPERATION errors.

This looks like a bug, but perhaps I shouldn't be calling glGetError
between glBegin/End anyway.

As always, thanks for the tremendous effort you guys put into this
library.

Allen

Re: [Mesa3d-dev] Bug in SI-GLU: invalid call to glMapGrid2f()

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

Diego Santa Cruz wrote:
> 
> Hi,
> 
> First of all thanks for the great work you have put on Mesa!
> 
> I've been using the SI-GLU for some time with Mesa-3.4.1 and I have come
> across what I think is a bug in the NURBS renderer of the SI GLU. In
> some cases it generates invalid calls to glMapGrid2f(), with a value of
> vn or un of zero. Since the SI GLU is being integrated in Mesa I think
> this is relevant here. I have submitted this to the SI mailing list but
> that appears to be almost abondoned. Since the SI GLU is being
> integrated in Mesa this might be the place to report it. Hope this is
> the correct mailing list.
> 
> Below is a copy of the message I sent to the SI mailing list at
> ogl...@os..., with a test program as well as a very simple
> patch that I think fixes the problem (as far as I could test, but my
> knowledge of the GLU implementation is very limited).

I'd send the report to the SI mailing list again.  The folks
who handle the SI at SGI are pretty busy but if you're persistant
somebody will eventually tend to it.

In the mean time, I'll apply your patch to the SI-GLU in the Mesa
source tree.

Thanks.

-Brian

Re: [Mesa3d-dev] CVS and SSE

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

Dieter Nützel wrote:
> 
> Am Montag, 30. April 2001 22:08 schrieb Dieter Nützel:
> > Am Montag, 30. April 2001 09:12 schrieb Sven M. Hallberg:
> > > On Mon, Apr 30, 2001 at 04:56:42AM +0200, Dieter N?tzel wrote:
> > > > OK, did cvs update -dPA.
> > > > This changed several files but know I get this:
> > > >
> > > > SunWave1>make distclean
> > > > Making distclean in .
> > > > make[1]: Entering directory `/opt/Mesa'
> > > > rm -f conf.h
> > > > rm -f TAGS ID
> > > > rm -f Makefile
> > > > rm -f config.cache config.log stamp-h stamp-h[0-9]*
> > > > rm -f libtool
> > > > make[1]: Leaving directory `/opt/Mesa'
> > > > Making distclean in util
> > > > make[1]: Entering directory `/opt/Mesa/util'
> > > > cd .. && automake --gnu util/Makefile
> > > > automake: couldn't open `common_rules.make': Datei oder Verzeichnis
> > > > nicht gefunden
> > > > make[1]: *** [Makefile.in] Error 2
> > > > make[1]: Leaving directory `/opt/Mesa/util'
> > > > make: *** [distclean-recursive] Error 1
> > >
> > > Do you have the common_rules.make file in your top Mesa source dir?
> >
> > I think I had.
> >
> > > Are you using GNU make?
> >
> > Yes, I do.
> >
> > > Try rerunning bootstrap.
> >
> 
> I did, again and build fail with the following.
> Normal build with "make -f Makefile.X11 linux-x86" works.
> 
> -Dieter
> 
> [-]
> In file included from fxtris.c:277:
> fxtritmp.h: In function `triangle_twoside_offset_flat_fallback_unfilled':
> fxtritmp.h:56: structure has no member named `data'
> fxtritmp.h:93: structure has no member named `data'
> fxtritmp.h: In function `quad_twoside_offset_flat_fallback_unfilled':
> fxtritmp.h:202: structure has no member named `data'
> fxtritmp.h:242: structure has no member named `data'
> fxtritmp.h: In function `line_twoside_offset_flat_fallback_unfilled':
> fxtritmp.h:318: structure has no member named `data'
> fxtritmp.h:327: structure has no member named `data'
> fxtritmp.h: In function `points_twoside_offset_flat_fallback_unfilled':
> fxtritmp.h:354: structure has no member named `data'
> fxtritmp.h:367: structure has no member named `data'
> make[3]: *** [fxtris.lo] Error 1
> make[3]: Leaving directory `/opt/Mesa/src/FX'
> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory `/opt/Mesa/src/FX'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory `/opt/Mesa/src'
> make: *** [check-recursive] Error 1
> 132.380u 26.900s 2:57.83 89.5%  0+0k 0+0io 567048pf+0w

The FX driver code needs some updates before it'll work again.
Keith will probably take care of the GLfloat-color changes and
I'll do the texture image changes.  Hopefully we'll get this
done within the week.

-Brian

Re: [Mesa3d-dev] CVS and SSE

[Dieter <Die...@ha...>]

Am Montag, 30. April 2001 22:08 schrieb Dieter Nützel:
> Am Montag, 30. April 2001 09:12 schrieb Sven M. Hallberg:
> > On Mon, Apr 30, 2001 at 04:56:42AM +0200, Dieter N?tzel wrote:
> > > OK, did cvs update -dPA.
> > > This changed several files but know I get this:
> > >
> > > SunWave1>make distclean
> > > Making distclean in .
> > > make[1]: Entering directory `/opt/Mesa'
> > > rm -f conf.h
> > > rm -f TAGS ID
> > > rm -f Makefile
> > > rm -f config.cache config.log stamp-h stamp-h[0-9]*
> > > rm -f libtool
> > > make[1]: Leaving directory `/opt/Mesa'
> > > Making distclean in util
> > > make[1]: Entering directory `/opt/Mesa/util'
> > > cd .. && automake --gnu util/Makefile
> > > automake: couldn't open `common_rules.make': Datei oder Verzeichnis
> > > nicht gefunden
> > > make[1]: *** [Makefile.in] Error 2
> > > make[1]: Leaving directory `/opt/Mesa/util'
> > > make: *** [distclean-recursive] Error 1
> >
> > Do you have the common_rules.make file in your top Mesa source dir?
>
> I think I had.
>
> > Are you using GNU make?
>
> Yes, I do.
>
> > Try rerunning bootstrap.
>

I did, again and build fail with the following.
Normal build with "make -f Makefile.X11 linux-x86" works.

-Dieter

[-]
In file included from fxtris.c:277:
fxtritmp.h: In function `triangle_twoside_offset_flat_fallback_unfilled':
fxtritmp.h:56: structure has no member named `data'
fxtritmp.h:93: structure has no member named `data'
fxtritmp.h: In function `quad_twoside_offset_flat_fallback_unfilled':
fxtritmp.h:202: structure has no member named `data'
fxtritmp.h:242: structure has no member named `data'
fxtritmp.h: In function `line_twoside_offset_flat_fallback_unfilled':
fxtritmp.h:318: structure has no member named `data'
fxtritmp.h:327: structure has no member named `data'
fxtritmp.h: In function `points_twoside_offset_flat_fallback_unfilled':
fxtritmp.h:354: structure has no member named `data'
fxtritmp.h:367: structure has no member named `data'
make[3]: *** [fxtris.lo] Error 1
make[3]: Leaving directory `/opt/Mesa/src/FX'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/opt/Mesa/src/FX'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/opt/Mesa/src'
make: *** [check-recursive] Error 1
132.380u 26.900s 2:57.83 89.5%  0+0k 0+0io 567048pf+0w

[Mesa3d-dev] recent eval fixes to 3.5

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

A couple of months ago (around the beginning of Febuary), I received a test
program that broke eval (nurbs) on 3.4 and 3.5.  I've just fixed the problems
on 3.5, but I no longer have details of who sent the test...

So.  If this command line looks familiar to you:

	./nurbs -s1 cart17s.txt 

Or you have sent a demo that produces a big red spiral when run like that, 
please try the latest trunk cvs to see if it fixes any other problems you've
had.

Keith

[Mesa3d-dev] Bug in SI-GLU: invalid call to glMapGrid2f()

[Diego S. C. <Die...@ep...>]

Hi,

First of all thanks for the great work you have put on Mesa!

I've been using the SI-GLU for some time with Mesa-3.4.1 and I have come
across what I think is a bug in the NURBS renderer of the SI GLU. In
some cases it generates invalid calls to glMapGrid2f(), with a value of
vn or un of zero. Since the SI GLU is being integrated in Mesa I think
this is relevant here. I have submitted this to the SI mailing list but
that appears to be almost abondoned. Since the SI GLU is being
integrated in Mesa this might be the place to report it. Hope this is
the correct mailing list.

Below is a copy of the message I sent to the SI mailing list at
ogl...@os..., with a test program as well as a very simple
patch that I think fixes the problem (as far as I could test, but my
knowledge of the GLU implementation is very limited).

Best regards,

	Diego

--

Hi there,

Sorry for sending this bug report to this mailing lits instead of
reporting it via bugzilla but I have been unable to get a password from
the bugzilla system (mail sent with password never arrived).

The bug is that the GLU nurbs renderer sometimes places invalid calls to
glMapGrid2f() with parameters 'un' and/or 'vn' of 0.

I have traced the bug to main/gfx/lib/glu/libnurbs/internals/slicer.cc
and I think I have fixed it in the patch which I attach.

The nurbs_revol.c program attached demonstrates the problem. Note that
it occurs only when using the GLU_NURBS_RENDERER, not with the
GLU_NURBS_TESSELLATOR (as it does not use GL evaluators).

If any help is needed you can contact me at my e-mail address (I'm not
member of this mailing list).

Best regards,

	Diego Santa Cruz

PS: I have tried the bug and it occurs on Irix machines (with the
shipped GLU) as well as Linux/i386 ones (with the SI-GLU compiled by
me).
-- 
-----------------------------------------------------------------------
Diego Santa Cruz                         mailto:Die...@ep...
Signal Processing Laboratory (LTS)        http://ltswww.epfl.ch/~dsanta
Swiss Federal Institute of Technology (EPFL)
EL - Ecublens - CH-1015 Lausanne - Switzerland
Office:     ELE 236
Phone:      +41 - 21 - 693 26 57 (Office)
            +41 - 21 - 693 46 20 (LTS Lab)                 *   *
Fax:        +41 - 21 - 693 76 00                           'O^-'
Mobile:     +41 - 79 - 375 50 60                           ( o )
-------------------------------------------------------- oOO U OOo ----

Re: [Mesa3d-dev] float color compile problem.

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi All,
> 
> I got the following compile problem on VMS:
> 
> cc /include=([-.include],[])/define=(PTHREADS=1)/name=(as_is,short) RASTPOS.C
> 
>    const GLchan *sumA = ctx->Light._BaseAlpha;
> ........................^
> %CC-W-PTRMISMATCH, In the initializer for sumA, the referenced type of the point
> er value "ctx->Light._BaseAlpha" is "float", which is not compatible with "const
>  unsigned char".
> at line number 108 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010501.MESA.SRC]RA
> STPOS.C;2
> 
> Probably something was missed when ewnabling floats for color indexing.
> 

I've done the obvious thing in that file, may need further testing.

Keith

[Mesa3d-dev] float color compile problem.

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

Hi All,

I got the following compile problem on VMS:

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

   const GLchan *sumA = ctx->Light._BaseAlpha;
........................^
%CC-W-PTRMISMATCH, In the initializer for sumA, the referenced type of the point
er value "ctx->Light._BaseAlpha" is "float", which is not compatible with "const
 unsigned char".
at line number 108 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010501.MESA.SRC]RA
STPOS.C;2


Probably something was missed when ewnabling floats for color indexing.

                    Jouk


Bush : All votes are equal but some votes are more equal than others.

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

  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] CVS and SSE

[Dieter <Die...@ha...>]

Am Montag, 30. April 2001 09:12 schrieb Sven M. Hallberg:
> On Mon, Apr 30, 2001 at 04:56:42AM +0200, Dieter N?tzel wrote:
> > OK, did cvs update -dPA.
> > This changed several files but know I get this:
> >
> > SunWave1>make distclean
> > Making distclean in .
> > make[1]: Entering directory `/opt/Mesa'
> > rm -f conf.h
> > rm -f TAGS ID
> > rm -f Makefile
> > rm -f config.cache config.log stamp-h stamp-h[0-9]*
> > rm -f libtool
> > make[1]: Leaving directory `/opt/Mesa'
> > Making distclean in util
> > make[1]: Entering directory `/opt/Mesa/util'
> > cd .. && automake --gnu util/Makefile
> > automake: couldn't open `common_rules.make': Datei oder Verzeichnis nicht
> > gefunden
> > make[1]: *** [Makefile.in] Error 2
> > make[1]: Leaving directory `/opt/Mesa/util'
> > make: *** [distclean-recursive] Error 1
>
> Do you have the common_rules.make file in your top Mesa source dir?

I think I had.

> Are you using GNU make?

Yes, I do.

> Try rerunning bootstrap.

I took a complete new Mesa CVS pull and it is running, now.

Only the DRI mesa-3.5-branch stop during the gamma stuff.

including in lib/GL/mesa/src/drv/common...
make[7]: Entering directory 
`/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc/lib/GL/mesa/src/drv/common'
make[7]: Leaving directory 
`/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc/lib/GL/mesa/src/drv/common'
including in lib/GL/mesa/src/drv/gamma...
make[7]: Entering directory 
`/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc/lib/GL/mesa/src/drv/gamma'
make[7]: *** No rule to make target `includes'.  Stop.
make[7]: Leaving directory 
`/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc/lib/GL/mesa/src/drv/gamma'
make[6]: *** [includes] Error 2
make[6]: Leaving directory 
`/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc/lib/GL/mesa/src/drv'
make[5]: *** [includes] Error 2
make[5]: Leaving directory 
`/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc/lib/GL/mesa/src'
make[4]: *** [includes] Error 2
make[4]: Leaving directory `/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc/lib/GL'
make[3]: *** [includes] Error 2
make[3]: Leaving directory `/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc/lib'
make[2]: *** [includes] Error 2
make[2]: Leaving directory `/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc'
make[1]: *** [Everything] Error 2
make[1]: Leaving directory `/tmp/INSTALL/SOURCE/dri-mesa-3.5/xc/xc'
make: *** [Everything] Error 2

Thanks to all of you!

-Dieter

Re: [Mesa3d-dev] CVS and SSE

[Sven M. H. <pe...@gm...>]

On Mon, Apr 30, 2001 at 04:56:42AM +0200, Dieter N?tzel wrote:
> OK, did cvs update -dPA.
> This changed several files but know I get this:
> 
> SunWave1>make distclean
> Making distclean in .
> make[1]: Entering directory `/opt/Mesa'
> rm -f conf.h
> rm -f TAGS ID
> rm -f Makefile
> rm -f config.cache config.log stamp-h stamp-h[0-9]*
> rm -f libtool
> make[1]: Leaving directory `/opt/Mesa'
> Making distclean in util
> make[1]: Entering directory `/opt/Mesa/util'
> cd .. && automake --gnu util/Makefile
> automake: couldn't open `common_rules.make': Datei oder Verzeichnis nicht 
> gefunden
> make[1]: *** [Makefile.in] Error 2
> make[1]: Leaving directory `/opt/Mesa/util'
> make: *** [distclean-recursive] Error 1

Do you have the common_rules.make file in your top Mesa source dir? Are you
using GNU make? Try rerunning bootstrap.


-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] CVS and SSE

[Sven M. H. <pe...@gm...>]

On Sun, Apr 29, 2001 at 05:14:47PM -0600, Brian Paul wrote:
> > > One problem is still outstanding.  The src/X86/gen_matypes.c file must
> > > be compiled and executed in order to generate src/X86/matypes.h before
> > > the assembly code can be compiled.  You can do this manually:
> > >
> > >       cd src/X86
> > >       gcc gen_matypes.c -I.. -I../../include -o gen_matypes
> > >       ./gen_matypes > matypes.h
> > >
> > > I don't know how to make configure do this.  When I make the MesaLib-3.5
> > > tarballs I'll include matypes.h so it won't be a problem for typical end
> > > users.  We developers and CVS users just have to remember to regenerate
> > > matypes.h whenever src/mtypes.h changes.
> > >
> > > I'll check in my updates ASAP.
> > >
> > > -Brian
> > 
> > I will have a look at the new matypes.h stuff (hopefully) soon. Brian, can you
> > give a (really) brief overview (pseudo-script or whatever) describing how the
> > steps needed to generate matypes.h?
> 
> I did above.  But really, I'm not sure this is too important.  When
> 3.5 is released it'll include the matypes.h file.  It's just when
> people download from CVS that they have to make/update the matypes.h
> file.

Ooops. Sorry, too tired by all those mails.


-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] CVS and SSE

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

Dieter N=FCtzel wrote:
>=20
> OK, did cvs update -dPA.
> This changed several files but know I get this:
>=20
> SunWave1>make distclean
> Making distclean in .
> make[1]: Entering directory `/opt/Mesa'
> rm -f conf.h
> rm -f TAGS ID
> rm -f Makefile
> rm -f config.cache config.log stamp-h stamp-h[0-9]*
> rm -f libtool
> make[1]: Leaving directory `/opt/Mesa'
> Making distclean in util
> make[1]: Entering directory `/opt/Mesa/util'
> cd .. && automake --gnu util/Makefile
> automake: couldn't open `common_rules.make': Datei oder Verzeichnis nic=
ht
> gefunden
> make[1]: *** [Makefile.in] Error 2
> make[1]: Leaving directory `/opt/Mesa/util'
> make: *** [distclean-recursive] Error 1
>=20
> Do you have the "older" bootstrap file handy?
> I lost it several weeks ago and it didn't reappear.

I still use the Makefile.X11 build stuff.  I know it works...

-- Gareth

Re: [Mesa3d-dev] CVS and SSE

[Dieter <Die...@ha...>]

Am Montag, 30. April 2001 04:42 schrieb Dieter Nützel:
> Am Montag, 30. April 2001 04:22 schrieb Gareth Hughes:
> > Dieter Nützel wrote:
> > > This haven't worked for me ever:-(
> > >
> > > ...
> > >
> > > Brian can you send me a copy, plese?
> > >
> > > Thank you very much.
> >
> > Are you sure you've got a clean version of the latest CVS code?
>
> Normally, yes. But who knows?
> I do cvs update -dP for ages...
>
> What next?

OK, did cvs update -dPA.
This changed several files but know I get this:

SunWave1>make distclean
Making distclean in .
make[1]: Entering directory `/opt/Mesa'
rm -f conf.h
rm -f TAGS ID
rm -f Makefile
rm -f config.cache config.log stamp-h stamp-h[0-9]*
rm -f libtool
make[1]: Leaving directory `/opt/Mesa'
Making distclean in util
make[1]: Entering directory `/opt/Mesa/util'
cd .. && automake --gnu util/Makefile
automake: couldn't open `common_rules.make': Datei oder Verzeichnis nicht 
gefunden
make[1]: *** [Makefile.in] Error 2
make[1]: Leaving directory `/opt/Mesa/util'
make: *** [distclean-recursive] Error 1

Do you have the "older" bootstrap file handy?
I lost it several weeks ago and it didn't reappear.

-Dieter

Re: [Mesa3d-dev] CVS and SSE

[Dieter <Die...@ha...>]

Am Montag, 30. April 2001 04:22 schrieb Gareth Hughes:
> Dieter Nützel wrote:
> > This haven't worked for me ever:-(
> >
> > ...
> >
> > Brian can you send me a copy, plese?
> >
> > Thank you very much.
>
> Are you sure you've got a clean version of the latest CVS code?

Normally, yes. But who knows?
I do cvs update -dP for ages...

What next?

-Dieter

Re: [Mesa3d-dev] CVS and SSE

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

Dieter N=FCtzel wrote:
>=20
> This haven't worked for me ever:-(
>=20
> ...
>=20
> Brian can you send me a copy, plese?
>=20
> Thank you very much.

Are you sure you've got a clean version of the latest CVS code?

-- Gareth

RE: [Mesa3d-dev] CVS and SSE

[Dieter <Die...@ha...>]

> >       cd src/X86
> >       gcc gen_matypes.c -I.. -I../../include -o gen_matypes
> >       ./gen_matypes > matypes.h
> >
> > I don't know how to make configure do this.  When I make the MesaLib-3.5
> > tarballs I'll include matypes.h so it won't be a problem for typical end
> > users.  We developers and CVS users just have to remember to regenerate
> > matypes.h whenever src/mtypes.h changes.
> >
> > I'll check in my updates ASAP.
> >
> > -Brian

This haven't worked for me ever:-(

SunWave1>cd /opt/Mesa/
Directory: /opt/Mesa
SunWave1>cd src/X86
Directory: /opt/Mesa/src/X86
SunWave1>gcc gen_matypes.c -I.. -I../../include -o gen_matypes
gcc: /opt/Mesa/src/X86/include: Datei oder Verzeichnis nicht gefunden
In file included from gen_matypes.c:41:
../mtypes.h:52: warning: `CHAN_MAX' redefined
../config.h:160: warning: this is the location of the previous definition
../mtypes.h:53: warning: `CHAN_MAXF' redefined
../config.h:161: warning: this is the location of the previous definition
In file included from gen_matypes.c:41:
../mtypes.h:115: redefinition of `GLcontext'
../config.h:197: `GLcontext' previously declared here
In file included from ../mtypes.h:1378,
                 from gen_matypes.c:41:
../dd.h:798: parse error before `points_func'
../dd.h:798: warning: no semicolon at end of struct or union
../dd.h:799: warning: data definition has no type or storage class
../dd.h:800: parse error before `TriangleFunc'
../dd.h:800: warning: data definition has no type or storage class
../dd.h:801: parse error before `QuadFunc'
../dd.h:801: warning: data definition has no type or storage class
../dd.h:802: parse error before `RectFunc'
../dd.h:802: warning: data definition has no type or storage class
../dd.h:828: parse error before `*'
../dd.h:828: warning: data definition has no type or storage class
../dd.h:829: parse error before `*'
../dd.h:829: warning: data definition has no type or storage class
../dd.h:830: parse error before `*'
../dd.h:830: warning: data definition has no type or storage class
../dd.h:899: warning: `struct gl_pipeline' declared inside parameter list
../dd.h:899: warning: its scope is only this definition or declaration, which 
is probably not what you want.
../dd.h:900: warning: `struct gl_pipeline' declared inside parameter list
../dd.h:958: parse error before `}'
In file included from gen_matypes.c:41:
../mtypes.h:1389: parse error before `GLvertexformat'
../mtypes.h:1389: warning: no semicolon at end of struct or union
../mtypes.h:1394: `GLvertexformat' undeclared here (not in a function)
../mtypes.h:1396: parse error before `}'
../mtypes.h:1427: field `Driver' has incomplete type
../mtypes.h:1569: field `TnlModule' has incomplete type
In file included from gen_matypes.c:42:
../tnl/t_context.h:513: parse error before `GLvertexformat'
../tnl/t_context.h:513: warning: no semicolon at end of struct or union
../tnl/t_context.h:515: warning: data definition has no type or storage class
SunWave1>./gen_matypes > matypes.h
./gen_matypes: Befehl nicht gefunden.

Brian can you send me a copy, plese?

Thank you very much.

-Dieter