mesa3d-dev

Re: [Mesa3d-dev] libtool problem

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

"Marcelo E. Magallon" wrote:
> 
> >> Brian Paul <br...@va...> writes:
> 
>  > >  run_cmd cat m4/*.m4 > acinclude.m4
>  > >  run_cmd libtoolize --automake --copy --force
>  > >  run_cmd aclocal
>  >
>  > Hmmm, I tried that but it didn't work (still no libtool).
> 
>  Weird.  Here's what I'm doing:
> 
>  $ vim bootstrap
>  [add the libtooline line, as show above]
>  $ cp /usr/share/aclocal/libtool.m4 m4/
>  $ ./bootstrap
>  $ ./configure
>  $ ls -l libtool
>  -rwxr-xr-x    1 marcelo  marcelo    146908 Jun 19 22:49 libtool
> 
>  The libtool.m4 I'm copying to m4 is the 1.4 one.  The one in m4 is
>  older, and it looks for a ltconfig script that the current libtoolize
>  script won't copy (it doesn't exist anymore)

That was the problem.  I was accidently using an older version of
libtool.m4.  Compilation is going now...

Thanks!

-Brian

Re: [Mesa3d-dev] libtool problem

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > >  run_cmd cat m4/*.m4 > acinclude.m4
 > >  run_cmd libtoolize --automake --copy --force
 > >  run_cmd aclocal
 > 
 > Hmmm, I tried that but it didn't work (still no libtool).

 Weird.  Here's what I'm doing:

 $ vim bootstrap 
 [add the libtooline line, as show above]
 $ cp /usr/share/aclocal/libtool.m4 m4/
 $ ./bootstrap
 $ ./configure 
 $ ls -l libtool
 -rwxr-xr-x    1 marcelo  marcelo    146908 Jun 19 22:49 libtool

 The libtool.m4 I'm copying to m4 is the 1.4 one.  The one in m4 is
 older, and it looks for a ltconfig script that the current libtoolize
 script won't copy (it doesn't exist anymore)

 > I'm including the matypes.h file in the tarballs that I make.

 Oh, ok.

-- 
Marcelo

Re: [Mesa3d-dev] libtool problem

[Marcelo E. M. <mar...@bi...>]

How nice, I was about to report this :-)

>> Brian Paul <br...@va...> writes:

 > I currently have autoconf 2.50, automake 1.4-p2 and libtool 1.4
 > installed.

 you need to copy your system's libtool.m4 to m4/libtool.m4 (mine is in
 /usr/share/aclocal/libtool.m4, I don't know if that's "standard"
 location)

 > Apparently, the 'libtoolize' program should be run during configure
 > in order to install 'libtool'.  But that's not happening.

 Nope, libtoolize is missing on the bootstrap script.  Something like
 this:

 run_cmd cat m4/*.m4 > acinclude.m4
 run_cmd libtoolize --automake --copy --force
 run_cmd aclocal

 > cd into your Mesa CVS directory
 > cvs up			// get latest sources
 > ln -s Mesa Mesa-3.5
 > cd Mesa-3.5
 > cp Makefile.X11 Makefile

 [insert ./bootstrap here]

 > make lib_tar demo_tar
 > 
 > // you should now have MesaLib-3.5.tar.gz and MesaDemos-3.5.tar.gz
 > 
 > cp Mesa*3.5.tar.gz /tmp
 > cd /tmp
 > tar zxf MesaLib-3.5.tar.gz
 > tar zxf MesaDemos-3.5.tar.gz
 > cd Mesa-3.5
 > ./configure
 > make
 > 
 > Compilation will fail because 'libtool' isn't found.

 Yes.  The one I'm trying to figure out is why autoheader is run after
 ./configure.  That shouldn't happen.

 The other problem is that matypes.h is not being generated.

-- 
Marcelo

Re: [Mesa3d-dev] libtool problem

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

"Marcelo E. Magallon" wrote:
> 
> How nice, I was about to report this :-)
> 
> >> Brian Paul <br...@va...> writes:
> 
>  > I currently have autoconf 2.50, automake 1.4-p2 and libtool 1.4
>  > installed.
> 
>  you need to copy your system's libtool.m4 to m4/libtool.m4 (mine is in
>  /usr/share/aclocal/libtool.m4, I don't know if that's "standard"
>  location)

OK.  I've added the m4/ directory to the tarball.


>  > Apparently, the 'libtoolize' program should be run during configure
>  > in order to install 'libtool'.  But that's not happening.
> 
>  Nope, libtoolize is missing on the bootstrap script.  Something like
>  this:
> 
>  run_cmd cat m4/*.m4 > acinclude.m4
>  run_cmd libtoolize --automake --copy --force
>  run_cmd aclocal

Hmmm, I tried that but it didn't work (still no libtool).


>  > cd into your Mesa CVS directory
>  > cvs up                       // get latest sources
>  > ln -s Mesa Mesa-3.5
>  > cd Mesa-3.5
>  > cp Makefile.X11 Makefile
> 
>  [insert ./bootstrap here]

Right.


>  > make lib_tar demo_tar
>  >
>  > // you should now have MesaLib-3.5.tar.gz and MesaDemos-3.5.tar.gz
>  >
>  > cp Mesa*3.5.tar.gz /tmp
>  > cd /tmp
>  > tar zxf MesaLib-3.5.tar.gz
>  > tar zxf MesaDemos-3.5.tar.gz
>  > cd Mesa-3.5
>  > ./configure
>  > make
>  >
>  > Compilation will fail because 'libtool' isn't found.
> 
>  Yes.  The one I'm trying to figure out is why autoheader is run after
>  ./configure.  That shouldn't happen.
> 
>  The other problem is that matypes.h is not being generated.

I'm including the matypes.h file in the tarballs that I make.

-Brian

[Mesa3d-dev] libtool problem

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

I need some help with autoconf and libtool.

Running ./configure should create or copy the 'libtool' program into
the Mesa-3.5/ directory (as it did in Mesa 3.4.x).  This isn't happening
on my system.  Any ideas why?

I currently have autoconf 2.50, automake 1.4-p2 and libtool 1.4
installed.

Apparently, the 'libtoolize' program should be run during configure
in order to install 'libtool'.  But that's not happening.

To reproduce what I'm doing:

cd into your Mesa CVS directory
cvs up			// get latest sources
ln -s Mesa Mesa-3.5
cd Mesa-3.5
cp Makefile.X11 Makefile
make lib_tar demo_tar

// you should now have MesaLib-3.5.tar.gz and MesaDemos-3.5.tar.gz

cp Mesa*3.5.tar.gz /tmp
cd /tmp
tar zxf MesaLib-3.5.tar.gz
tar zxf MesaDemos-3.5.tar.gz
cd Mesa-3.5
./configure
make

Compilation will fail because 'libtool' isn't found.

-Brian

[Mesa3d-dev] 3.5 release soon

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

I hope to release Mesa 3.5 in the next couple days.  I'm just doing
some last-minute bug fixing and build testing now.  I encourage
people to grab the CVS sources and give it a try.  A lot of things
have changed since the 3.4 branch.

-Brian

Re: [Mesa3d-dev] Unaligned traps in __indirect_glFrustum

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

"Mike A. Harris" wrote:
> 
> I just recently recieved this bug report from an Alpha user.
> 
> Description of Problem:
> 
> The problem manifests itself in Mesa but this is really g_render.c
> trouble so it belongs to X.
> 
> Various programs from "Mesa-demos" are consistently getting on Alpha
> a number of "unaligned trap" errors.  Like this:
> 
> cubemap(16472): unaligned trap at 0000020000590334: 000002000002a03c 27 2
> cubemap(16472): unaligned trap at 0000020000590344: 000002000002a044 27 3
> cubemap(16472): unaligned trap at 0000020000590348: 000002000002a04c 27 4
> cubemap(16472): unaligned trap at 0000020000590350: 000002000002a054 27 5
> 
> With Mesa-3.4.1 recompiled for debugging and run from a shell which
> forces SIGBUS, instead of a fixup, on an unaligned trap 'gdb' reveals
> this:
> 
> Starting program: /usr/bin/gears
> 
> Program received signal SIGBUS, Bus error.
> __indirect_glFrustum (left=-1, right=1, bottom=-1, top=1, zNear=5, zFar=60)
>     at g_render.c:2523
> 2523            __GLX_PUT_DOUBLE(12,right);
> 
> Starting program: /usr/bin/bounce
> 
> Program received signal SIGBUS, Bus error.
> __indirect_glOrtho (left=-8.0000002384185791, right=8.0000002384185791,
>     bottom=-6, top=6, zNear=-6, zFar=6) at g_render.c:2590
> 2590            __GLX_PUT_DOUBLE(12,right);
> 
> Starting program: /usr/bin/gamma
> 
> Program received signal SIGBUS, Bus error.
> __indirect_glOrtho (left=-1, right=1, bottom=-1, top=1, zNear=-1, zFar=1)
>     at g_render.c:2590
> 2590            __GLX_PUT_DOUBLE(12,right);
> 
> Starting program: /usr/bin/cubemap
> GL_REFLECTION_MAP_ARB mode
> keys:
>   SPACE - toggle animation
>   CURSOR KEYS - rotation
>   m - toggle texgen reflection mode
> 
> Program received signal SIGBUS, Bus error.
> __indirect_glFrustum (left=-2, right=2, bottom=-2, top=2, zNear=6, zFar=20)
>     at g_render.c:2523
> 2523            __GLX_PUT_DOUBLE(12,right);
> 
> This is a backtrace for 'bounce'
> 
> #0  __indirect_glOrtho (left=-8.0000002384185791, right=8.0000002384185791,
>     bottom=-6, top=6, zNear=-6, zFar=6) at g_render.c:2590
> #1  0x20000412588 in glOrtho (left=-8.0000002384185791,
>     right=8.0000002384185791, bottom=-6, top=6, nearval=-6, farval=6)
>     at glapitemp.h:938
> #2  0x120001a8c in reshape (width=5889, height=172080) at bounce.c:92
> #3  0x200001409f8 in processWindowWorkList (window=0x120105170)
>     at glut_event.c:1193
> #4  0x20000140cc8 in __glutProcessWindowWorkLists () at glut_event.c:1328
> #5  0x20000140d74 in glutMainLoop () at glut_event.c:1349
> #6  0x120002240 in main (argc=1, argv=0x11ffff7b8) at bounce.c:218
> 
> and this is for 'cubemap'.
> 
> #0  __indirect_glFrustum (left=-2, right=2, bottom=-2, top=2, zNear=6,
> zFar=20)
>     at g_render.c:2523
> #1  0x2000040fc08 in glFrustum (left=-2, right=2, bottom=-2, top=2,
> nearval=6,
>     farval=20) at glapitemp.h:513
> #2  0x1200017a8 in reshape (width=300, height=300) at cubemap.c:144
> #3  0x200001409f8 in processWindowWorkList (window=0x120104b40)
>     at glut_event.c:1193
> #4  0x20000140cc8 in __glutProcessWindowWorkLists () at glut_event.c:1328
> #5  0x20000140d74 in glutMainLoop () at glut_event.c:1349
> #6  0x120001cfc in main (argc=5889, argv=0x2000002a030) at cubemap.c:248
> 
> And this is the code in question, from __indirect_glFrustum, after macros
> were expanded:
> 
>         *((INT16 *) (pc +  0 )) =   52   ;
>         *((INT16 *) (pc +  2 )) = 175     ;
>         *((FLOAT64 *) (pc +  4 )) =  left  ;
>         *((FLOAT64 *) (pc +  12 )) =  right  ;
>         *((FLOAT64 *) (pc +  20 )) =  bottom  ;
>         *((FLOAT64 *) (pc +  28 )) =  top  ;
>         *((FLOAT64 *) (pc +  36 )) =  zNear  ;
>         *((FLOAT64 *) (pc +  44 )) =  zFar  ;
> 
> Unaligned access can be silent elsewhere but it is a performance drag on
> any architecture.
> 
>    Michal
>    mi...@ha...
> 


The preprocessor token __GLX_ALIGN64 should fix that.  The
__GLX_PUT_DOUBLE() macro is defined as follows:

#ifdef __GLX_ALIGN64
/*
** This can certainly be done better for a particular machine
** architecture!
*/
#define __GLX_PUT_DOUBLE(offset,a) \
    __GLX_MEM_COPY(pc + offset, &a, 8)
#else
#define __GLX_PUT_DOUBLE(offset,a) \
    *((FLOAT64 *) (pc + offset)) = a
#endif


The following patch should fix this:

Index: Imakefile
===================================================================
RCS file: /cvsroot/dri/xc/xc/lib/GL/glx/Imakefile,v
retrieving revision 1.10
diff -r1.10 Imakefile
89a90,92
> #if defined(AlphaArchitecture)
>      GLX_DEFS = GlxDefines -D__GLX_ALIGN64
> #else
90a94,95
> #endif
> 


-Brian

Autoreply: [Mesa3d-dev] Unaligned traps in __indirect_glFrustum (fwd)

[Mike A. H. <mh...@re...>]

Please remove subscriber.
Thanks.




----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing

---------- Forwarded message ----------
Date: Sat, 16 Jun 2001 09:57:21 +0100
From: me...@ow...
To: mh...@re...
Subject: Autoreply: [Mesa3d-dev] Unaligned traps in __indirect_glFrustum

Thanks for the email.

I'll be unavailable to reply until 25th June. If you need to get a message to me before then, please contact Panasonic Owl (+44 131 555 6055) who can relay the message on.

Thanks
Andy Methley

[Mesa3d-dev] Unaligned traps in __indirect_glFrustum

[Mike A. H. <mh...@re...>]

I just recently recieved this bug report from an Alpha user.

Description of Problem:

The problem manifests itself in Mesa but this is really g_render.c
trouble so it belongs to X.

Various programs from "Mesa-demos" are consistently getting on Alpha
a number of "unaligned trap" errors.  Like this:

cubemap(16472): unaligned trap at 0000020000590334: 000002000002a03c 27 2
cubemap(16472): unaligned trap at 0000020000590344: 000002000002a044 27 3
cubemap(16472): unaligned trap at 0000020000590348: 000002000002a04c 27 4
cubemap(16472): unaligned trap at 0000020000590350: 000002000002a054 27 5

With Mesa-3.4.1 recompiled for debugging and run from a shell which
forces SIGBUS, instead of a fixup, on an unaligned trap 'gdb' reveals
this:

Starting program: /usr/bin/gears

Program received signal SIGBUS, Bus error.
__indirect_glFrustum (left=-1, right=1, bottom=-1, top=1, zNear=5, zFar=60)
    at g_render.c:2523
2523		__GLX_PUT_DOUBLE(12,right);


Starting program: /usr/bin/bounce

Program received signal SIGBUS, Bus error.
__indirect_glOrtho (left=-8.0000002384185791, right=8.0000002384185791,
    bottom=-6, top=6, zNear=-6, zFar=6) at g_render.c:2590
2590		__GLX_PUT_DOUBLE(12,right);


Starting program: /usr/bin/gamma

Program received signal SIGBUS, Bus error.
__indirect_glOrtho (left=-1, right=1, bottom=-1, top=1, zNear=-1, zFar=1)
    at g_render.c:2590
2590		__GLX_PUT_DOUBLE(12,right);

Starting program: /usr/bin/cubemap
GL_REFLECTION_MAP_ARB mode
keys:
  SPACE - toggle animation
  CURSOR KEYS - rotation
  m - toggle texgen reflection mode

Program received signal SIGBUS, Bus error.
__indirect_glFrustum (left=-2, right=2, bottom=-2, top=2, zNear=6, zFar=20)
    at g_render.c:2523
2523		__GLX_PUT_DOUBLE(12,right);

This is a backtrace for 'bounce'

#0  __indirect_glOrtho (left=-8.0000002384185791, right=8.0000002384185791,
    bottom=-6, top=6, zNear=-6, zFar=6) at g_render.c:2590
#1  0x20000412588 in glOrtho (left=-8.0000002384185791,
    right=8.0000002384185791, bottom=-6, top=6, nearval=-6, farval=6)
    at glapitemp.h:938
#2  0x120001a8c in reshape (width=5889, height=172080) at bounce.c:92
#3  0x200001409f8 in processWindowWorkList (window=0x120105170)
    at glut_event.c:1193
#4  0x20000140cc8 in __glutProcessWindowWorkLists () at glut_event.c:1328
#5  0x20000140d74 in glutMainLoop () at glut_event.c:1349
#6  0x120002240 in main (argc=1, argv=0x11ffff7b8) at bounce.c:218


and this is for 'cubemap'.

#0  __indirect_glFrustum (left=-2, right=2, bottom=-2, top=2, zNear=6,
zFar=20)
    at g_render.c:2523
#1  0x2000040fc08 in glFrustum (left=-2, right=2, bottom=-2, top=2,
nearval=6,
    farval=20) at glapitemp.h:513
#2  0x1200017a8 in reshape (width=300, height=300) at cubemap.c:144
#3  0x200001409f8 in processWindowWorkList (window=0x120104b40)
    at glut_event.c:1193
#4  0x20000140cc8 in __glutProcessWindowWorkLists () at glut_event.c:1328
#5  0x20000140d74 in glutMainLoop () at glut_event.c:1349
#6  0x120001cfc in main (argc=5889, argv=0x2000002a030) at cubemap.c:248

And this is the code in question, from __indirect_glFrustum, after macros
were expanded:

        *((INT16 *) (pc +  0 )) =   52   ;
	*((INT16 *) (pc +  2 )) = 175     ;
	*((FLOAT64 *) (pc +  4 )) =  left  ;
        *((FLOAT64 *) (pc +  12 )) =  right  ;
        *((FLOAT64 *) (pc +  20 )) =  bottom  ;
        *((FLOAT64 *) (pc +  28 )) =  top  ;
        *((FLOAT64 *) (pc +  36 )) =  zNear  ;
        *((FLOAT64 *) (pc +  44 )) =  zFar  ;


Unaligned access can be silent elsewhere but it is a performance drag on
any architecture.

   Michal
   mi...@ha...






----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing

Re: [Mesa3d-dev] patch for some type alias bugs

[Josh V. <ho...@na...>]

Brian Paul <br...@va...> writes:

> Klaus Niederkrueger wrote:
> > 
> > Hi,
> > 
> > Some time ago I wrote saying that I had problems with the square-root
> > functions in the file 'src/mmath.c' when compiling with
> > '-fstrict-aliasing' (on RedHat7.0), so I guess that a similar patch as
> > Josh's should be applied to 'mmath.c' in lines like
> > 
> > float f;
> > unsigned int *fi = (unsigned int *)&f;
> >                       /* to access the bits of a float in */
> >                       /* C quickly we must misuse pointers */
> 
> Can you try doing that on your system?  Let me know if a change is
> needed.

How does FAST_MATH get defined?  I was going to fix that one until I
realized it wasn't even being compiled on my system.  I can't find any
Makefile targets that define it.

Josh

Re: [Mesa3d-dev] patch for some type alias bugs

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

Klaus Niederkrueger wrote:
> 
> Hi,
> 
> Some time ago I wrote saying that I had problems with the square-root
> functions in the file 'src/mmath.c' when compiling with
> '-fstrict-aliasing' (on RedHat7.0), so I guess that a similar patch as
> Josh's should be applied to 'mmath.c' in lines like
> 
> float f;
> unsigned int *fi = (unsigned int *)&f;
>                       /* to access the bits of a float in */
>                       /* C quickly we must misuse pointers */

Can you try doing that on your system?  Let me know if a change is
needed.

-Brian

Re: [Mesa3d-dev] patch for some type alias bugs

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

Josh Vanderhoof wrote:
> 
> Here's a patch that fixes some type alias bugs that show up with
> -fstrict-aliasing on gcc (which will be the default for gcc 3.0).  For
> the most part the patch just changes instances of
> 
>         *(xtype *)&y
> 
> which could possibly read from the address &y before the value of y
> has been written out to memory due to C aliasing rules, with
> 
>         ((union { xtype xt; ytype yt;} *)&y)->xt
> 
> which is safe for gcc since the created pointer can alias both xtype
> and ytype.  Hopefully other compilers will also assume union pointers
> can alias all of their member types.

I've applied the patch.  I put the typedef for fi_type in glheader.h
so it can be easily used anywhere.

-Brian

Re: [Mesa3d-dev] read/write_rgba_span_rgba for OSMesa CHAN_BITS=16

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

"J.P. Delport" wrote:
> 
> Brian Paul wrote:
> >
> > "J.P. Delport" wrote:
> >
> > > I also did some GLchan fixes in read/write_rgba_span_rgba in osmesa.c
> > >
> > > The functions appear to work correctly for 16 bit/channel (and should
> > > for 32 bit). They follow at the bottom. I don't know if the ASSERT in
> > > the write function can be removed completely.
> >
> > This is incorrect.  The write_rgba_span_rgba() function will only work
> > correctly for 8-bit channels.  The reason is we're using a GLuint to
> > store 4 8-bit channels at once as a dword.  By storing 4 bytes at once
> > (without any swizzling) we can get slightly better performance.  But
> > if we're storing > 4 bytes or need swizzling, we need to use the slower
> > write_rgba_span() function.
> 
> Sorry, I missed the idea behind the use of the GLint. Still, the case
> for CHAN_BITS=16 with no swizzling is also a special case and could be
> made faster by using MEMCPY, escpecially when there is no mask.

Yes, that could be done.  Feel free to submit a patch. :)


> Also: in the function write_rgb_span the alpha values passed to
> PACK_RGBA are 255???

I'm replacing 255 with CHAN_MAX.  Thanks.

-Brian

Re: [Mesa3d-dev] read/write_rgba_span_rgba for OSMesa CHAN_BITS=16

[J.P. D. <jpd...@cs...>]

Brian Paul wrote:
> 
> "J.P. Delport" wrote:
>
> > I also did some GLchan fixes in read/write_rgba_span_rgba in osmesa.c
> >
> > The functions appear to work correctly for 16 bit/channel (and should
> > for 32 bit). They follow at the bottom. I don't know if the ASSERT in
> > the write function can be removed completely.
> 
> This is incorrect.  The write_rgba_span_rgba() function will only work
> correctly for 8-bit channels.  The reason is we're using a GLuint to
> store 4 8-bit channels at once as a dword.  By storing 4 bytes at once
> (without any swizzling) we can get slightly better performance.  But
> if we're storing > 4 bytes or need swizzling, we need to use the slower
> write_rgba_span() function.

Sorry, I missed the idea behind the use of the GLint. Still, the case
for CHAN_BITS=16 with no swizzling is also a special case and could be
made faster by using MEMCPY, escpecially when there is no mask.

Also: in the function write_rgb_span the alpha values passed to
PACK_RGBA are 255???

jp

Re: [Mesa3d-dev] patch for some type alias bugs

[Klaus N. <kl...@ma...>]

Hi,

Some time ago I wrote saying that I had problems with the square-root
functions in the file 'src/mmath.c' when compiling with
'-fstrict-aliasing' (on RedHat7.0), so I guess that a similar patch as
Josh's should be applied to 'mmath.c' in lines like

float f;
unsigned int *fi = (unsigned int *)&f;
                      /* to access the bits of a float in */
                      /* C quickly we must misuse pointers */


Greetings,

	Klaus

[Mesa3d-dev] patch for some type alias bugs

[Josh V. <ho...@na...>]

Here's a patch that fixes some type alias bugs that show up with
-fstrict-aliasing on gcc (which will be the default for gcc 3.0).  For
the most part the patch just changes instances of

        *(xtype *)&y

which could possibly read from the address &y before the value of y
has been written out to memory due to C aliasing rules, with

        ((union { xtype xt; ytype yt;} *)&y)->xt

which is safe for gcc since the created pointer can alias both xtype
and ytype.  Hopefully other compilers will also assume union pointers
can alias all of their member types.

Josh

Index: src/mmath.h
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/mmath.h,v
retrieving revision 1.38
diff -u -r1.38 mmath.h
--- src/mmath.h	2001/06/04 14:33:33	1.38
+++ src/mmath.h	2001/06/15 00:59:44
@@ -206,6 +206,8 @@
 
 
 
+#define GET_FLOAT_BITS(x) ((union { GLfloat f; GLuint i; } *)&(x))->i
+
 /*
  * Float -> Int conversions (rounding, floor, ceiling)
  */
@@ -406,7 +408,9 @@
 #define CLAMPED_FLOAT_TO_UBYTE(b, f) \
         UNCLAMPED_FLOAT_TO_UBYTE(b, f)
 
-#define COPY_FLOAT( dst, src )		*(GLuint *)&(dst) = *(GLuint *)&(src)
+#define COPY_FLOAT( dst, src )					\
+	((union { GLuint i; GLfloat f; } *)&(dst))->i = 	\
+	 ((union { GLuint i; GLfloat f; } *)&(src))->i
 
 #else /* USE_IEEE */
 
Index: src/texutil.c
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/texutil.c,v
retrieving revision 1.24
diff -u -r1.24 texutil.c
--- src/texutil.c	2001/05/02 21:02:38	1.24
+++ src/texutil.c	2001/06/15 00:59:45
@@ -415,7 +415,7 @@
 	  dst = (s >> 1) | ((s & 1) << 15); }
 
 #define CONVERT_TEXEL_DWORD( dst, src )					\
-	{ const GLuint s = *(GLuint *)src;				\
+	{ const GLuint s = ((union { GLuint i; GLushort s; } *)src)->i;	\
 	  dst = (((s & 0xfffefffe) >> 1) |				\
 		 ((s & 0x00010001) << 15)); }
 
Index: src/tnl/t_imm_api.c
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/tnl/t_imm_api.c,v
retrieving revision 1.15
diff -u -r1.15 t_imm_api.c
--- src/tnl/t_imm_api.c	2001/06/04 16:09:28	1.15
+++ src/tnl/t_imm_api.c	2001/06/15 00:59:48
@@ -543,12 +543,15 @@
 #define NORMALF( x, y, z )					\
 {								\
    GLuint count;						\
-   GLint *normal;						\
+   typedef union { GLfloat f; GLint i; } fi_type;		\
+   fi_type *normal;						\
    GET_IMMEDIATE;						\
    count = IM->Count;						\
    IM->Flag[count] |= VERT_NORM;				\
-   normal = (GLint *)IM->Normal[count];				\
-   ASSIGN_3V(normal, *(int*)&(x), *(int*)&(y), *(int*)&(z));	\
+   normal = (fi_type *)IM->Normal[count];			\
+   normal[0].i = ((fi_type *)&(x))->i;				\
+   normal[1].i = ((fi_type *)&(y))->i;				\
+   normal[2].i = ((fi_type *)&(z))->i;				\
 }
 #else
 #define NORMALF NORMAL
@@ -616,18 +619,19 @@
 }
 
 #if defined(USE_IEEE)
-#define TEXCOORD2F(s,t)				\
-{						\
-   GLuint count;				\
-   GLint *tc;					\
-   GET_IMMEDIATE;				\
-   count = IM->Count;				\
-   IM->Flag[count] |= VERT_TEX0;		\
-   tc = (GLint *)IM->TexCoord0[count];		\
-   tc[0] = *(GLint *)&(s);			\
-   tc[1] = *(GLint *)&(t);			\
-   tc[2] = 0;					\
-   tc[3] = IEEE_ONE;				\
+#define TEXCOORD2F(s,t)					\
+{							\
+   GLuint count;					\
+   typedef union { GLfloat f; GLint i; } fi_type;	\
+   fi_type *tc;						\
+   GET_IMMEDIATE;					\
+   count = IM->Count;					\
+   IM->Flag[count] |= VERT_TEX0;			\
+   tc = (fi_type *)IM->TexCoord0[count];		\
+   tc[0].i = ((fi_type *)&(s))->i;			\
+   tc[1].i = ((fi_type *)&(t))->i;			\
+   tc[2].i = 0;						\
+   tc[3].i = IEEE_ONE;					\
 }
 #else
 #define TEXCOORD2F TEXCOORD2
@@ -721,53 +725,56 @@
 }
 
 #if defined(USE_IEEE)
-#define VERTEX2F(IM, x, y)			\
-{						\
-   GLuint count = IM->Count++;			\
-   GLint *dest = (GLint *)IM->Obj[count];	\
-   IM->Flag[count] |= VERT_OBJ; 		\
-   dest[0] = *(GLint *)&(x);			\
-   dest[1] = *(GLint *)&(y);			\
-   dest[2] = 0;					\
-   dest[3] = IEEE_ONE;				\
+#define VERTEX2F(IM, x, y)				\
+{							\
+   GLuint count = IM->Count++;				\
+   typedef union { GLfloat f; GLint i; } fi_type;	\
+   fi_type *dest = (fi_type *)IM->Obj[count];		\
+   IM->Flag[count] |= VERT_OBJ; 			\
+   dest[0].i = ((fi_type *)&(x))->i;			\
+   dest[1].i = ((fi_type *)&(y))->i;			\
+   dest[2].i = 0;					\
+   dest[3].i = IEEE_ONE;				\
 /*     ASSERT(IM->Flag[IM->Count]==0); */		\
    if (count == IMM_MAXDATA - 1)			\
-      _tnl_flush_immediate( IM );		\
+      _tnl_flush_immediate( IM );			\
 }
 #else
 #define VERTEX2F VERTEX2
 #endif
 
 #if defined(USE_IEEE)
-#define VERTEX3F(IM, x, y, z)			\
-{						\
-   GLuint count = IM->Count++;			\
-   GLint *dest = (GLint *)IM->Obj[count];	\
-   IM->Flag[count] |= VERT_OBJ_23;		\
-   dest[0] = *(GLint *)&(x);			\
-   dest[1] = *(GLint *)&(y);			\
-   dest[2] = *(GLint *)&(z);			\
-   dest[3] = IEEE_ONE;				\
-/*     ASSERT(IM->Flag[IM->Count]==0);	 */	\
+#define VERTEX3F(IM, x, y, z)				\
+{							\
+   GLuint count = IM->Count++;				\
+   typedef union { GLfloat f; GLint i; } fi_type;	\
+   fi_type *dest = (fi_type *)IM->Obj[count];		\
+   IM->Flag[count] |= VERT_OBJ_23;			\
+   dest[0].i = ((fi_type *)&(x))->i;			\
+   dest[1].i = ((fi_type *)&(y))->i;			\
+   dest[2].i = ((fi_type *)&(z))->i;			\
+   dest[3].i = IEEE_ONE;				\
+/*     ASSERT(IM->Flag[IM->Count]==0);	 */		\
    if (count == IMM_MAXDATA - 1)			\
-      _tnl_flush_immediate( IM );		\
+      _tnl_flush_immediate( IM );			\
 }
 #else
 #define VERTEX3F VERTEX3
 #endif
 
 #if defined(USE_IEEE)
-#define VERTEX4F(IM, x, y, z, w)		\
-{						\
-   GLuint count = IM->Count++;			\
-   GLint *dest = (GLint *)IM->Obj[count];	\
-   IM->Flag[count] |= VERT_OBJ_234;		\
-   dest[0] = *(GLint *)&(x);			\
-   dest[1] = *(GLint *)&(y);			\
-   dest[2] = *(GLint *)&(z);			\
-   dest[3] = *(GLint *)&(w);			\
+#define VERTEX4F(IM, x, y, z, w)			\
+{							\
+   GLuint count = IM->Count++;				\
+   typedef union { GLfloat f; GLint i; } fi_type;	\
+   fi_type *dest = (fi_type *)IM->Obj[count];		\
+   IM->Flag[count] |= VERT_OBJ_234;			\
+   dest[0].i = ((fi_type *)&(x))->i;			\
+   dest[1].i = ((fi_type *)&(y))->i;			\
+   dest[2].i = ((fi_type *)&(z))->i;			\
+   dest[3].i = ((fi_type *)&(w))->i;			\
    if (count == IMM_MAXDATA - 1)			\
-      _tnl_flush_immediate( IM );		\
+      _tnl_flush_immediate( IM );			\
 }
 #else
 #define VERTEX4F VERTEX4
@@ -886,12 +893,13 @@
    GLuint texunit = target - GL_TEXTURE0_ARB;			\
    if (texunit < IM->MaxTextureUnits) {				\
       GLuint count = IM->Count;					\
-      GLint *tc = (GLint *)IM->TexCoord[texunit][count];	\
+      typedef union { GLfloat f; GLint i; } fi_type;		\
+      fi_type *tc = (fi_type *)IM->TexCoord[texunit][count];	\
       IM->Flag[count] |= VERT_TEX(texunit);			\
-      tc[0] = *(int *)&(s);					\
-      tc[1] = *(int *)&(t);					\
-      tc[2] = 0;						\
-      tc[3] = IEEE_ONE;						\
+      tc[0].i = ((fi_type *)&(s))->i;				\
+      tc[1].i = ((fi_type *)&(t))->i;				\
+      tc[2].i = 0;						\
+      tc[3].i = IEEE_ONE;					\
    }								\
 }
 #else
Index: src/tnl/t_vb_render.c
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/tnl/t_vb_render.c,v
retrieving revision 1.20
diff -u -r1.20 t_vb_render.c
--- src/tnl/t_vb_render.c	2001/05/11 15:53:06	1.20
+++ src/tnl/t_vb_render.c	2001/06/15 00:59:48
@@ -69,8 +69,8 @@
 
 
 #if defined(USE_IEEE)
-#define NEGATIVE(x) ((*(GLuint *)&x) & (1<<31))
-#define DIFFERENT_SIGNS(x,y) (((*(GLuint *)&x)^(*(GLuint *)&y)) & (1<<31))
+#define NEGATIVE(x) (GET_FLOAT_BITS(x) & (1<<31))
+#define DIFFERENT_SIGNS(x,y) ((GET_FLOAT_BITS(x) ^ GET_FLOAT_BITS(y)) & (1<<31))
 #else
 #define NEGATIVE(x) (x < 0)
 #define DIFFERENT_SIGNS(x,y) (x * y <= 0 && x - y != 0)

Re: [Mesa3d-dev] read/write_rgba_span_rgba for OSMesa CHAN_BITS=16

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

"J.P. Delport" wrote:
> 
> Hello,
> 
> I've found that these faster MEMCPY functions were not selected for 16
> (or 32-bit for that matter) bit/channel OSMesa.
> 
> I enabled them by taking out the check for CHAN_BITS==8 in osmesa.c in
> the function osmesa_update_state under where it says /* 4 bytes / pixel
> in frame buffer */ ... This could be renamed 4 GLchan / pixel or
> someting.

Done.


> I also did some GLchan fixes in read/write_rgba_span_rgba in osmesa.c
> 
> The functions appear to work correctly for 16 bit/channel (and should
> for 32 bit). They follow at the bottom. I don't know if the ASSERT in
> the write function can be removed completely.

This is incorrect.  The write_rgba_span_rgba() function will only work
correctly for 8-bit channels.  The reason is we're using a GLuint to
store 4 8-bit channels at once as a dword.  By storing 4 bytes at once
(without any swizzling) we can get slightly better performance.  But
if we're storing > 4 bytes or need swizzling, we need to use the slower
write_rgba_span() function.


> I was also playing around with compiling the osmesa lib with
> CHAN_BITS=32 and it broke quite a lot of functions mainly at bit shifts.
> How can I compile the lib with some functions modified (the ones that
> are going to be called by my 32bit/chan program for checking) and some
> others unchanged? Can I safely #if functions out that would not compile
> with CHAN_BITS=32, but that are not going to be called? I'm interested
> in getting 32bit/chan smoothed triangles rendered.

CHAN_BITS=32 doesn't work yet.  It'll require a lot of changes that
I haven't implemented yet.  Specifically, the triangle and line
rasterization templates use fixed-point arithmetic for color interpolation.
That'll all need to be changed for 32-bit floating point colors.

-Brian

[Mesa3d-dev] read/write_rgba_span_rgba for OSMesa CHAN_BITS=16

[J.P. D. <jpd...@cs...>]

Hello,

I've found that these faster MEMCPY functions were not selected for 16
(or 32-bit for that matter) bit/channel OSMesa.

I enabled them by taking out the check for CHAN_BITS==8 in osmesa.c in
the function osmesa_update_state under where it says /* 4 bytes / pixel
in frame buffer */ ... This could be renamed 4 GLchan / pixel or
someting.

I also did some GLchan fixes in read/write_rgba_span_rgba in osmesa.c

The functions appear to work correctly for 16 bit/channel (and should
for 32 bit). They follow at the bottom. I don't know if the ASSERT in
the write function can be removed completely.

I was also playing around with compiling the osmesa lib with
CHAN_BITS=32 and it broke quite a lot of functions mainly at bit shifts.
How can I compile the lib with some functions modified (the ones that
are going to be called by my 32bit/chan program for checking) and some
others unchanged? Can I safely #if functions out that would not compile
with CHAN_BITS=32, but that are not going to be called? I'm interested
in getting 32bit/chan smoothed triangles rendered.

cheers
jp

read/write functions:

/* Write RGBA pixels to an RGBA buffer.  This is the fastest
span-writer. */
static void
write_rgba_span_rgba( const GLcontext *ctx, GLuint n, GLint x, GLint y,
                      CONST GLchan rgba[][4], const GLubyte mask[] )
{
   OSMesaContext osmesa = OSMESA_CONTEXT(ctx);
   GLchan *ptr4 = PIXELADDR4(x, y);
   GLuint i;
   /*ASSERT(CHAN_TYPE == GL_UNSIGNED_BYTE);*/
   if (mask) {
     for (i = 0; i < n; i++, ptr4 += 4) {
         if (mask[i]) {
            PACK_RGBA(ptr4, rgba[i][RCOMP], rgba[i][GCOMP],
                         rgba[i][BCOMP], rgba[i][ACOMP]);
         }
      } 
   }
   else {
      MEMCPY( ptr4, rgba, n * 4 * sizeof(GLchan));
   }
}

/* Read RGBA pixels from an RGBA buffer */
static void
read_rgba_span_rgba( const GLcontext *ctx, GLuint n, GLint x, GLint y,
                     GLchan rgba[][4] )
{
   OSMesaContext osmesa = OSMESA_CONTEXT(ctx);
   GLchan *ptr4 = PIXELADDR4(x, y);
   MEMCPY( rgba, ptr4, n * 4 * sizeof(GLchan) );
}

Re: [Mesa3d-dev] Certification

[Stephen J B. <sj...@li...>]

On Sun, 10 Jun 2001, Iftach Hyams wrote:

> Does anybody knows about an effort to get an OpenGL verification to
> Mesa implementation ?
 
I don't - but the OpenGL compliance suite gets run on Mesa at intervals
and it seems that it passes with essentially complete success every
time.

I doubt Mesa could ever be *FORMALLY* verified as a legitimate OpenGL
implementation because:

  1) Being OpenSourced, it changes on a daily basis and may have been
     modified on every machine it runs on.  Hence the verification could
     only apply to very particular versions.

  2) Someone would have to pay SGI's license fee.  It's hard to imagine
     a strong motivation for doing that.  Everyone who cares knows that
     Mesa *is* OpenGL (although we aren't allowed to *say* that...so I
     shouldn't)...do we really need to spend all that money to say so?

  3) With a large number of platforms to support (several OS's, many
     graphics cards and lots of different CPU's), you'd probably have
     to verify every combination for this to be in any way useful.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Mesa3d-dev] Certification

[Iftach H. <par...@el...>]

 Does anybody knows about an effort to get an OpenGL verification to
Mesa implementation ?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DOES THE NAME PAVLOV RING A BELL?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Iftach Hyams
E.S.L. Haifa
972 - 4 - 831 5605
par...@el...

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

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

On Thu, Jun 07, 2001 at 11:30:22PM +0200, Marcelo E. Magallon wrote:
> >> li...@th... writes:
> 
>  > So the 1.2 is "static"? Have you looked at -release? I don't know what
>  > this will do to the SONAME though. It won't give you the name above
>  > but close enough (libGL-1.2.xxyyzz.so).
> 
>  This is the problem.  In this case the soname *must* be libGL.so.1 (on
>  Linux).  The problem is that the library is provided by several
>  vendors, and a sane development environment is needed: if I compile foo
>  with a particular vendor's version it must run with all the others.
>  The exposed interface is well defined and this level of compatibility
>  is achievable.  Mesa is unique in that it's available for a multitude
>  of platforms.  Linux is the only one where this issue is critical (it'd
>  be nice if Mesa used the native libgl's soname on every platfrom, but
>  it's just a minor issue)

As far as my understanding goes, the only platform where we're concerned about
the naming of the library archive and the soname is Linux right now, because
there exists an OpenGL ABI we need to follow WRT to the soname, and a common
convention for naming the archive file we wouldn't want to break with, either.

Therefore I think it is okay if we inspect the way libtool works on this
particular platform and devise a scheme which takes advantage of that, in
order to conform to the standards governing us (again only on that particular
platform). If further platforms with different conventions appear, we will
have to adopt specific strategies for them as well, of course.


Additionally I want to follow up to the argument against using generating
CURRENT, REVISION, and AGE in any other way than that described in the libtool
docs:

I have read the entire libtool documentation, and reread the version-info part
thoroughly for this particular problem. I fully agree with libtool's scheme of
encapsulating library version details behind an abstract interface. There's
actually no point in arguing against that.

With the above in mind, I was very careful to devise a scheme which would,
regardless of the concrete archive name and soname for now, first of all _not_
defy the purpose and meaning of libtool's version-info. I believe that, what 
I have come up with fully satisfies that requirement because the version-info
it creates (see my earlier post for a description) is still nothing else than
a description of the interface(s) the library implements. The reason is the
fact that the OpenGL interface is exactly defined by the OpenGL standard.
That standard has a clear versioning scheme which guarantees that any
interface change will be reflected by a corresponding version number change.
Finally, we use only that version number for the CURRENT and AGE fields.

As far as REVISION is concerned, libtool states that it is used to choose one
of multiple libraries implementing the _same_ interfaces. The only property
required of the number used as REVISION is that, for two libs of the same
interface, the greater REVISION number is to be preferred. Clearly the mesa
version number has that property.


I think the above shows that the proposed scheme does not conflict with any
libtool idiom, therefore justifying the call for a REVISION field supporting
large enough integers.


Best regards,
Sven

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

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

[David S. M. <da...@re...>]

Brian Paul writes:
 > Log message:
 >   use unoptimized COPY_4UBV code on SPARC to avoid memory alignment problems (bug 430689)

This is surely not a Sparc specific problem.

Any RISC machine is going to take an exception if you access unaligned
bytes as a word.  Only on x86 is this optimization going to work
reliably.

On some RISC machines, such unaligned loads work from the user's
perspective, but these "work" by trapping into the kernel to get
"fixed up".  This could lead to hard to detect performance problems in
Mesa.

I would suggest disabling this optimization on all non-x86 systems.

Later,
David S. Miller
da...@re...

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

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

"David S. Miller" wrote:
> 
> Brian Paul writes:
>  > Log message:
>  >   use unoptimized COPY_4UBV code on SPARC to avoid memory alignment problems (bug 430689)
> 
> This is surely not a Sparc specific problem.
> 
> Any RISC machine is going to take an exception if you access unaligned
> bytes as a word.  Only on x86 is this optimization going to work
> reliably.
> 
> On some RISC machines, such unaligned loads work from the user's
> perspective, but these "work" by trapping into the kernel to get
> "fixed up".  This could lead to hard to detect performance problems in
> Mesa.
> 
> I would suggest disabling this optimization on all non-x86 systems.

Good point.  Other than x86 I only occasionally test Mesa on a
MIPS-based SGI system- though it hasn't been a problem there (might
just be getting lucky).  But I know that alignment is important on
most RISC systems.  I'll change the test.

-Brian

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

[Marcelo E. M. <mar...@bi...>]

>> "Lars J. Aas" <la...@si...> writes:

 > Another digression; I'd like to know what you meant with the "mostly non
 > issue" comment.

 I forgot there's still a "Professional Edition" of Coin, and that even
 LGPL Coin is anything but dead.  My mistake.

 WRT ABI compatibility, it should be possible with gcc 3.0.  Other
 compilers are a different can of worms.

-- 
Marcelo

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

[Lars J. A. <la...@si...>]

On Thu, Jun 07, 2001 at 11:30:22PM +0200, Marcelo E. Magallon wrote:
:  needs a way to be able to set the soname.  Yes, this is bad in general.
:  It defeats the whole purpose of libtool, but the problem is that Mesa
:  is providing another version of an existing library.  I can imagine
:  things like Motif (lesstif), OpenInventor (Coin, mostly non issue now)
:  are in the same situation.

Just to digress; for Coin we use the soname libCoin.so.#.#.# (normal
libtool version-info) because Open Inventor is C++, and achieving
ABI-compatibility with it is impossible.  I don't even think either
SGI or TGS Open Inventor is ABI-compatible with itself for many
version-increments at a time.  Of course, your point is still valid
for the situation with Mesa and Lesstif.

Another digression; I'd like to know what you meant with the "mostly non
issue" comment.

  Lars J