mesa3d-dev

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

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

Brian Paul wrote:
> 
> This code in texutil.c:
> 
> #define CONVERT_TEXEL_DWORD( src )                                      \
>                 ({ GLuint s = *(GLuint *)src;                           \
>                    s = (((s & 0xfffefffe) >> 1) |                       \
>                         ((s & 0x00010001) << 15)); s; })
> 
> is not ANSI-legal.
> 
> I'll fix it up.

If possible, can you do it without changing the template file?  Thanks. 
Inline functions should do the trick.  And I just built standalone Mesa
and discovered this fact, not that I'm surprised or anything :-)

> With these latest changes it appears to me that the Format and Type
> fields in gl_texture_image are redundant with respect to the BaseFormat
> and BaseType fields in the gl_texture_format struct.  I'd like to
> remove Format and Type from the former and use the later instead.
> I'll work on that too.

I'm still trying to work out the best way to handle format and type info
for the hardware-format images.  So far, I've used types like
GL_UNSIGNED_SHORT_5_6_5 and so on, but kept the base format as one of
the original legal base format values (ie. I'm not using GL_BGRA
combined with the *_REV types).  I'm ultra-busy with other stuff, so
feel free to do this.

I guess my biggest aim here is to remove all the massive case statements
that check the format and type info.  It might be worth storing the
number of components in gl_texture_format as well, for instance.

-- Gareth

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

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

Gareth Hughes wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/src/
> Changes by:     gareth@usw-pr-cvs1.     01/03/27 11:18:02
> 
> Log message:
>   Updates required for DRI drivers on mesa-3-5-branch.
> 
> Modified files:
>       Mesa/src/:
>         imports.c mtypes.h texformat.c texstore.c texutil.c
> 
>   Revision      Changes    Path
>   1.9           +10 -8     Mesa/src/imports.c
>   1.33          +4 -1      Mesa/src/mtypes.h
>   1.4           +63 -36    Mesa/src/texformat.c
>   1.19          +13 -5     Mesa/src/texstore.c
>   1.19          +41 -1     Mesa/src/texutil.c

This code in texutil.c:

#define CONVERT_TEXEL_DWORD( src )					\
		({ GLuint s = *(GLuint *)src;				\
		   s = (((s & 0xfffefffe) >> 1) |			\
			((s & 0x00010001) << 15)); s; })

is not ANSI-legal.

I'll fix it up.


Gareth,

With these latest changes it appears to me that the Format and Type
fields in gl_texture_image are redundant with respect to the BaseFormat
and BaseType fields in the gl_texture_format struct.  I'd like to
remove Format and Type from the former and use the later instead.
I'll work on that too.

-Brian

[Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

[Dirk R. <re...@ig...>]

On Mar 23, 11:37pm, Sven M. Hallberg wrote:
> Subject: Re: [Mesa3d-users] configure problem (was Missing GLX
extensions)
>
> If your compiler/preprocessor docs don't give enough information,
running a
> test file containing __FILE__ and __LINE__ through the preprocessor
should
> suffice.

Hmm, it's a little more complicated. They are preprocessor symbols, but
__LINE__ is just a number, not text. Thus __FILE__ ":" __LINE__ doesn't
work. Using #__LINE__ doesn't, either, as # only works for function macro
arguments. And putting __LINE__ in a function macro gives you "__LINE__",
which is not very helpful.

You could switch to a printf solution, but I'm tempted to just go the VMS
route: ignore it. I guess the whole thing is just for internal developers,
very few of which will use an sgi. And those could kludge something
themselves.

> Right, will remove it right after I send this mail out.

Yup, works now.

> Oh, so it's your equivalent to what's called libstdc++ on my system?

If I knew what libstdc++ did I could tell you, but I guess the answer is
yes. ;)

>
> Right, it's strange. Did the linker give you an indication where the Cio
> symbols were referenced?
>
>-- End of excerpt from Sven M. Hallberg

Running the files through nm and grepping gave me the list given below. I
guess just including -lCio for the executables should be an acceptable
fix.

Yours

	Dirk


__dl__GPv is in
./libnurbs/nurbtess/sampledLine.lo
./libnurbs/nurbtess/sampleCompRight.lo
./libnurbs/nurbtess/gridWrap.lo
./libnurbs/nurbtess/sampleMonoPoly.lo
./libnurbs/nurbtess/monoTriangulation.lo
./libnurbs/nurbtess/sampleComp.lo
./libnurbs/nurbtess/primitiveStream.lo
./libnurbs/nurbtess/directedLine.lo
./libnurbs/nurbtess/rectBlock.lo
./libnurbs/nurbtess/monoChain.lo
./libnurbs/internals/slicer.lo
./libnurbs/internals/subdivider.lo
./libnurbs/internals/mesher.lo
./libnurbs/internals/flist.lo
./libnurbs/internals/coveandtiler.lo
./libnurbs/internals/curvelist.lo
./libnurbs/internals/patchlist.lo
./libnurbs/internals/dataTransform.lo
./libnurbs/internals/varray.lo
./libnurbs/internals/uarray.lo
./libnurbs/internals/displaylist.lo
./libnurbs/internals/trimline.lo
./libnurbs/internals/bufpool.lo
./libnurbs/internals/knotvector.lo
./libnurbs/internals/trimvertpool.lo
./libnurbs/internals/bin.lo
./libnurbs/internals/tobezier.lo
./libnurbs/internals/arctess.lo
./libnurbs/internals/hull.lo
./libnurbs/internals/nurbsinterfac.lo
./libnurbs/interface/glinterface.lo
./libnurbs/interface/glrenderer.lo
./libnurbs/interface/glcurveval.lo
./libnurbs/interface/glsurfeval.lo

__pure_virtual_called is in
./libnurbs/internals/basicsurfeval.lo

__vtbl__9type_info is in
./libnurbs/internals/flistsorter.lo
./libnurbs/internals/sorter.lo
./libnurbs/internals/nurbstess.lo
./libnurbs/internals/basicsurfeval.lo
./libnurbs/internals/arcsorter.lo
./libnurbs/internals/basiccrveval.lo
./libnurbs/internals/cachingeval.lo
./libnurbs/interface/glrenderer.lo
./libnurbs/interface/glcurveval.lo
./libnurbs/interface/glsurfeval.lo



-- 
--
-- Dirk Reiners             re...@ig..., Dir...@gm... 
-- OpenSG Forum                                http://www.opensg.org
-- Rundeturmstrasse 6                 http://www.igd.fhg.de/~reiners
-- D-64283 Darmstadt                 All standard disclaimers apply. 
-- Truth is stranger than fiction because fiction has to make sense. 

[Mesa3d-dev] Texture utils

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

Just in case you aren't already convinced, this is how easy it was to
special-case a commonly-used Tribes2 texture format:

#define CONVERT_TEXEL( src )						\
		({ GLushort s = *(GLushort *)src;			\
		   s = (s >> 1) | ((s & 1) << 15); s; })

#define CONVERT_TEXEL_DWORD( src )					\
		({ GLuint s = *(GLuint *)src;				\
		   s = (((s & 0xfffefffe) >> 1) |			\
			((s & 0x00010001) << 15)); s; })

#define SRC_TEXEL_BYTES		2

#define TAG(x) x##_rgba5551_to_argb1555
#define PRESERVE_DST_TYPE
#include "texutil_tmp.h"

Nice n' easy...

-- Gareth

Re: [Mesa3d-dev] gl_sqrt in mmath.c

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

David Konerding <de...@ko...> writes:

> > But with '-fstrict-aliasing', which was used in my auto-generated
> > Makefile for Mesa, the results for sqrt are for some numbers up to
> > 10 times greater than the once generated by gl_sqrt, while the
> > speed for normal sqrt is still higher.
>
> Did you read the man page for gcc and learn what -fstrict-aliasing
> does?  I wouldn't use that feature for math-intensive routines.

I don't know of any reason why math-intensive routines would be
affected by -fstrict-aliasing.  However, it does matter for what gcc
calls 'type punning' (accessing one type as if it were another type),
which Mesa does a lot of.

GCC will handle this ok:

int get_float_bits(float f)
{
        union { int i; float f; } n;

        n.f = f;

        return n.i;
}

But it is allowed to screw this up:

int get_float_bits(float f)
{
        return *(int *)&f;
}

Most of the type puns in mmath use unions, but it looks like there are
several occurrences of *(type *)&var scattered around (one is at the
begining of gl_sqrt()).  Someone should get rid of them so we can
compile with strict aliasing.


Josh

Re: [Mesa3d-dev] gl_sqrt in mmath.c

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

I don't know if you understand me: I did not change the
'gl_sqrt'-function, I only analysed it to see what it produces both in
speed and accuracy.

On Mon, 26 Mar 2001, David Konerding wrote:
>
> There are a number of issues here.  You can't just play with compiler
> optimization flags willy-nilly.

I know. I played with the flags that are used by Makefile generated by
'./configure'.

> is NOT acceptable).  You don't mean "precision", you mean "accuracy", and for
> those of where it matters
Sorry, English is not my mother-tongue.

>
> Did you read the man page for gcc and learn what -fstrict-aliasing does?  I
> wouldn't use that
> feature for math-intensive routines.
>
Like I said above, I only used it because it was used in 'configure.in'.

> So it's a 20 or 30 digit number ... what's the error?  Binary representation
> of floating point is a very, very ugly numerical situation,
> it's not surprising to me you get some garbage off to the right- what really
> matters is the raw error,
> between the numerically correct answer and your approximate solution.

What I did was 'sqrt(x)/gl_sqrt(x)' and I something like '10^30'
instead of '10^0' (I got a 30 digit number in front of the dot).

>
> You should also remote -ffast-math from your compile line, it's a dubious
> routine, and I'm sure there is at least one
> place where Mesa violates the rules that -ffast-math assumes you're following.
>

'-ffast-math' is also used in the standard Makefiles of Mesa.

Klaus

Re: [Mesa3d-dev] gl_sqrt in mmath.c

[David K. <de...@ko...>]

Klaus Niederkrueger wrote:

> Hi,
>
> I have been thinking about making a faster 'log_2' function by programming
> it myself instead of using the one in libc.
> I started by looking at the gl_sqrt function that is being used in the
> Mesa-library in the file 'src/mmath.c'.
>
> I made a small program to test both the speed and the precision and at
> home on a K6-2 with Debian-2.1 I had a rather terrible result: If I did
> not use the compiler-option '-fstrict-aliasing' the libc-sqrt is almost
> double as fast as the 'gl_sqrt', while the precision is o.k. 1% error or
> so.

There are a number of issues here.  You can't just play with compiler
optimization flags willy-nilly.
Furthermore, I think you need to be a bit more careful with your numerical
analysis (1% error in sqrt
is NOT acceptable).  You don't mean "precision", you mean "accuracy", and for
those of where it matters
that the image quality is high, accuracy of square root is very important.

>
>
> But with '-fstrict-aliasing', which was used in my auto-generated Makefile
> for Mesa, the results for sqrt are for some numbers up to 10 times greater
> than the once generated by gl_sqrt, while the speed for normal sqrt is
> still higher.
>

Did you read the man page for gcc and learn what -fstrict-aliasing does?  I
wouldn't use that
feature for math-intensive routines.

>
> So I wanted  to write you and tell this but then I just tried my program
> here on a PIII whith RH7.0 I got complete different results: gl_sqrt is a
> bit faster than sqrt, and 'strict-aliasing' has no effect on speed or
> results. The error in the results is always up to 20%. If I use
> '-mcpu=pentium-pro -march=pentium-pro' the precision is completely wrong
> (20 or 30 digit number instead of 1.000).
>

RH7.0 has a different version of the compiler, modified by Red Hat.  An
there were a lot of changes in the compiler since the version in Debian 2.1.
A LOT of changes.
What do you mean "the precision is completely wrong" when you use
"-mcpu-pentium-pro -march=pentium-pro"?
So it's a 20 or 30 digit number ... what's the error?  Binary representation
of floating point is a very, very ugly numerical situation,
it's not surprising to me you get some garbage off to the right- what really
matters is the raw error,
between the numerically correct answer and your approximate solution.

You should also remote -ffast-math from your compile line, it's a dubious
routine, and I'm sure there is at least one
place where Mesa violates the rules that -ffast-math assumes you're following.

[Mesa3d-dev] gl_sqrt in mmath.c

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

Hi,

I have been thinking about making a faster 'log_2' function by programming
it myself instead of using the one in libc.
I started by looking at the gl_sqrt function that is being used in the
Mesa-library in the file 'src/mmath.c'.

I made a small program to test both the speed and the precision and at
home on a K6-2 with Debian-2.1 I had a rather terrible result: If I did
not use the compiler-option '-fstrict-aliasing' the libc-sqrt is almost
double as fast as the 'gl_sqrt', while the precision is o.k. 1% error or
so.

But with '-fstrict-aliasing', which was used in my auto-generated Makefile
for Mesa, the results for sqrt are for some numbers up to 10 times greater
than the once generated by gl_sqrt, while the speed for normal sqrt is
still higher.

So I wanted  to write you and tell this but then I just tried my program
here on a PIII whith RH7.0 I got complete different results: gl_sqrt is a
bit faster than sqrt, and 'strict-aliasing' has no effect on speed or
results. The error in the results is always up to 20%. If I use
'-mcpu=pentium-pro -march=pentium-pro' the precision is completely wrong
(20 or 30 digit number instead of 1.000).

Maybe you want to try yourself and find out if I did something wrong or
what could be happening.

To compile put the program below into Mesa/src and I compiled at home with

gcc -I../include -ffast-math -fexpensive-optimizations -fstrict-aliasing
-mcpu=k6 -march=k6 -DUSE_X86_ASM -DFAST_MATH -O3 test.c mmath.c -o test

The program is:


#include "mmath.h"
#include <time.h>

#define NEW_SQRT(X) gl_sqrt(X)
#define OLD_SQRT(X) ((float)sqrt(X))

int main()
{
float x,y;
clock_t start, end;

_mesa_init_math();

x = 0.0f;
y = 0.0f;

start = clock();
while (x<1000000.0f)
{
        y *= NEW_SQRT(x);
        x += 0.1f;
}
end = clock();

printf ("Time for mesa sqrt: %f\n", (float)(end-start)/CLOCKS_PER_SEC);

x = 0.0f;
y = 0.0f;

start = clock ();
while (x<1000000.0f)
{
        y *= OLD_SQRT(x);
        x += 0.1f;
}
end = clock();

printf ("Time for normal sqrt: %f\n", (float)(end-start)/CLOCKS_PER_SEC);

x= 1.0f;
while (x<100.0f)
{
printf("x = %f\tMesa_square(x)/standard_square(x) = %f\n", x,
OLD_SQRT(x)/NEW_SQ
RT(x));
x+=2.4;
}
}

Re: [Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > But what about __FILE__ and __LINE__?

 Preprocessor macros.  __FUNCTION__ is defined by the compiler because
 the preprocessor doesn't know about functions.  Conversely, the
 compiler doesn't know about __FILE__ and __LINE__ because its input has
 been preprocessed (it gets the info via #line directives)

-- 
Marcelo

Re: [Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

On Sat, Mar 24, 2001 at 02:57:56PM +0100, Marcelo E. Magallon wrote:
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > The difference it makes is that, if they are both preprocessor macros that
>  > expand to _string_ constants, we could simply
> 
>  __FUNCTION__ (and __PRETTY_FUNCTION__) are string variables.  From the
>  gcc manual:

But what about __FILE__ and __LINE__?

-- 
@SVEN_M_HALLBERG@ <$(pesco_gmx.de)>
"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] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > The difference it makes is that, if they are both preprocessor macros that
 > expand to _string_ constants, we could simply

 __FUNCTION__ (and __PRETTY_FUNCTION__) are string variables.  From the
 gcc manual:

 > These names are not macros: they are predefined string variables.
 > For example, `#ifdef __FUNCTION__' does not have any special meaning
 > inside a function, since the preprocessor does not do anything
 > special with the identifier `__FUNCTION__'.  

-- 
Marcelo

[Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

On Thu, Mar 22, 2001 at 10:32:10PM +0100, Dirk Reiners wrote:
> > Right. Are those two preprocessor macros or real variables?
> 
> I think the former. Does it make a difference and how do I check?

The difference it makes is that, if they are both preprocessor macros that
expand to _string_ constants, we could simply

#define __FUNCTION__ "unknown function at " __FILE__ ":" __LINE__

However if that's not the case we need to use a function call to create a
single sensable string from them. Some sprintf-like thing that uses and
returns a static buffer for the string would probably be best:

#define __FUNCTION__ mesa_static_sprintf("unknown function at %s:%d", \
                                         __FILE__, __LINE__);

If your compiler/preprocessor docs don't give enough information, running a
test file containing __FILE__ and __LINE__ through the preprocessor should
suffice.


> > Hehe. I've noticed that flag, too. Actually asked about it's purpose on
> > mesa3d-dev. Generates a warning on my system, so I'm ignoring it until
> someone
> > tells me I can safely remove it (*wink*).
> 
> Well, it creates an error on Irix, i.e. no compile. If nobody knows what
> it's good for, maybe now is a good time to get rid of it. ;)

Right, will remove it right after I send this mail out.


> > libCio? Never heard of that. And what does it have to do with C++
> streams?
> > Can you give me a description of the circumstances under which this
> library is
> > needed so I can model a proper check for it? It's not available on my
> machine.
> 
> It's part of the current STL. It contains the little code that is created
> and needed by STL, mainly stream stuff, some complex number functions etc.

Oh, so it's your equivalent to what's called libstdc++ on my system?


> It is needed on Irix as soon as the 'std' namespace STL is used (BTW, if
> that happens you also need the -LANG:std option). You can easily test if
> you need by running the following program:
> 
> #include <iostream>
> 
> int main( int argc, char *argv[] )
> {
>         std::cout;
> }
> 
> If it works you don't need to do anything special, if it gives an error
> you need -lCio. By default the compiler includes it automatically, but
> libtool apparently works around that, so you'll have to use libtool to
> check it.

OK, thanks, will write the check tomorrow probably.


> I don't really understand why it is needed for si-glu, I couldn't find
> streams in there, maybe it was something else. It's just confusing that
> you don't need the -LANG:std option, usually it complains if you use the
> std namespace, and if you don't use that, why does it need the libCio.so?
> Something's fishy here but I'm not sure what it is.

Right, it's strange. Did the linker give you an indication where the Cio
symbols were referenced?


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-users] configure problem (was Missing GLX extensions)

[Dirk R. <re...@ig...>]

On Mar 21,  5:36pm, Sven M. Hallberg wrote:
> Subject: Re: [Mesa3d-users] configure problem (was Missing GLX
extensions)
>
> Well I guess we'll just change it there for now and leave everything
> else untouched unless it becomes a problem.

OK.

>
> Right. Are those two preprocessor macros or real variables?

I think the former. Does it make a difference and how do I check?

> Hehe. I've noticed that flag, too. Actually asked about it's purpose on
> mesa3d-dev. Generates a warning on my system, so I'm ignoring it until
someone
> tells me I can safely remove it (*wink*).

Well, it creates an error on Irix, i.e. no compile. If nobody knows what
it's good for, maybe now is a good time to get rid of it. ;)

> libCio? Never heard of that. And what does it have to do with C++
streams?
> Can you give me a description of the circumstances under which this
library is
> needed so I can model a proper check for it? It's not available on my
machine.

It's part of the current STL. It contains the little code that is created
and needed by STL, mainly stream stuff, some complex number functions etc.

It is needed on Irix as soon as the 'std' namespace STL is used (BTW, if
that happens you also need the -LANG:std option). You can easily test if
you need by running the following program:

#include <iostream>

int main( int argc, char *argv[] )
{
        std::cout;
}

If it works you don't need to do anything special, if it gives an error
you need -lCio. By default the compiler includes it automatically, but
libtool apparently works around that, so you'll have to use libtool to
check it.

I don't really understand why it is needed for si-glu, I couldn't find
streams in there, maybe it was something else. It's just confusing that
you don't need the -LANG:std option, usually it complains if you use the
std namespace, and if you don't use that, why does it need the libCio.so?
Something's fishy here but I'm not sure what it is.

>-- End of excerpt from Sven M. Hallberg

Yours

	Dirk

-- 
--
-- Dirk Reiners             re...@ig..., Dir...@gm... 
-- OpenSG Forum                                http://www.opensg.org
-- Rundeturmstrasse 6                 http://www.igd.fhg.de/~reiners
-- D-64283 Darmstadt                 All standard disclaimers apply. 
-- Truth is stranger than fiction because fiction has to make sense. 

RE: [Mesa3d-dev] Seriously off-topic question...

[<her...@ru...>]

Thank everyone for the quick answers... they helped a lot!

- Heriberto Delgado
  (her...@ru...)

-----Original Message-----
From: mes...@li...
[mailto:mes...@li...]On Behalf Of Stephen J
Baker
Sent: Jueves, 22 de Marzo de 2001 12:49 p.m.
To: io...@cr...
Cc: mes...@li...
Subject: Re: [Mesa3d-dev] Seriously off-topic question...


Oe Thu, 22 Mar 2001 her...@ru... wrote:

> 
> Hello! I'm really sorry if this question bothers you in any way, but it
> seems this
> is the only place I can ask it and actually receive a reasonable answer.

You'd stand a VERY good chance of getting an answer if you posted it to
the 'gdalgorithms' list.  They *thrive* on questions like this.

  gda...@li...

Subscribe at Sourceforge.

> Is there any way I can calculate the area of a triangle defined by his
> vertices  (x1,y1) - (x2,y2) - (x3,y3) WITHOUT the use of SQRT() in any
> part of the formula?

Yes.  (That was easy!)

...oh - you want to know *HOW* as well...OK.

Here are the steps needed to calculate the area of a 2D polygon. It
doesn't matter if the polygon is listed in a clockwise or
counter-clockwise order, it can be convex or concave, or even
self-intersect.

  /*
    x & y are arrays containing the x and y coordinates
    of the polygon vertices.

    npoints is the number of points in each list.
  */

  double area ( int npoints, double *x, double *y )
  {
    double area = 0.0 ;

    for ( int i = 0 ; i < npoints ; i++ )
    {
      int ii = (i+1) % npoints ;

      area += x[i] * y[ii] - x[ii] * y[i] ;
    }

    return fabs ( area / 2.0 ) ;
  }

----
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 mailing list
Mes...@li...
http://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

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

On Thu, Mar 22, 2001 at 11:55:09AM -0700, Keith Whitwell wrote:
> Look at the drivers in the Mesa tree.  Look at the FX driver.  The DRI drivers
> are just like this, but they have additional dependencies on code inside
> XFree86.
> 
> Core mesa (Mesa/src, Mesa/src/tnl, Mesa/src/swrast, etc) does exactly the same
> thing in both places.  It's the same code.  

Oh I see.


> You may just have to knuckle down and read some code...

Oh well, I always feared it would end this way... ;)
I guess I'll do that then when I get time.


Thanks for the info.

-- 
@SVEN_M_HALLBERG@ <$(pesco_gmx.de)>
"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] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

On Thu, Mar 22, 2001 at 12:00:29PM -0700, Keith Whitwell wrote:
> As much as I like and value __FUNCTION__ for working with templates, I'm
> tempted to say we shouldn't allow it into CVS.

I wouldn't be that absolute. As long as we perform a clean check, thus
assuming it being defined, one way or the other, I'd say we use it.

-- 
@SVEN_M_HALLBERG@ <$(pesco_gmx.de)>
"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] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

On Thu, Mar 22, 2001 at 11:04:44AM -0700, Brian Paul wrote:
> Karl Schultz wrote:
> > __FUNCTION__ is a problem for Windows as well.
> > 
> > It would be nice to have
> > 
> > #if defined(VMS) || defined(WIN32)
> > #define __FUNCTION__
> > #endif
> > 
> > in texutil_tmp.h
> 
> Better yet:
> 
> #ifndef __FUNCTION__
> #define __FUNCTION__ "<some function>"
> #endif

As Antti mentioned, __FUNCTION__ is a gcc-builtin _variable_, not a
preprocessor macro.

Furthermore, shouldn't we rather check whether the compiler supports it at
configure time? I guess there's a GCC for VMS, or not?
Anyways, even a VMS or Win32 compiler might support __FUNCTION__, so it
wouldn't be wise to just check for VMS/WIN32 being #define'd, but rather
#define some other macro, in Make-config or by the configure script
respectively and check that one.

What do you think?

-- 
@SVEN_M_HALLBERG@ <$(pesco_gmx.de)>
"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] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

[Antti T. <se...@si...>]

On Thu, 22 Mar 2001, Brian Paul wrote:

> > __FUNCTION__ is a problem for Windows as well.
> >
> > It would be nice to have
> >
> > #if defined(VMS) || defined(WIN32)
> > #define __FUNCTION__
> > #endif
> >
> > in texutil_tmp.h
>
> Better yet:
>
> #ifndef __FUNCTION__
> #define __FUNCTION__ "<some function>"
> #endif

That would define __FUNCTION__ as "<some function>" with
gcc also, the only way to get through that is

#ifndef __GNUC__
#define __FUNCTION__ "<some function>"
#endif

Works for me.

___
Antti Tapaninen
se...@si...

Re: [Mesa3d-dev] Seriously off-topic question...

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

Oe Thu, 22 Mar 2001 her...@ru... wrote:

> 
> Hello! I'm really sorry if this question bothers you in any way, but it
> seems this
> is the only place I can ask it and actually receive a reasonable answer.

You'd stand a VERY good chance of getting an answer if you posted it to
the 'gdalgorithms' list.  They *thrive* on questions like this.

  gda...@li...

Subscribe at Sourceforge.

> Is there any way I can calculate the area of a triangle defined by his
> vertices  (x1,y1) - (x2,y2) - (x3,y3) WITHOUT the use of SQRT() in any
> part of the formula?

Yes.  (That was easy!)

...oh - you want to know *HOW* as well...OK.

Here are the steps needed to calculate the area of a 2D polygon. It
doesn't matter if the polygon is listed in a clockwise or
counter-clockwise order, it can be convex or concave, or even
self-intersect.

  /*
    x & y are arrays containing the x and y coordinates
    of the polygon vertices.

    npoints is the number of points in each list.
  */

  double area ( int npoints, double *x, double *y )
  {
    double area = 0.0 ;

    for ( int i = 0 ; i < npoints ; i++ )
    {
      int ii = (i+1) % npoints ;

      area += x[i] * y[ii] - x[ii] * y[i] ;
    }

    return fabs ( area / 2.0 ) ;
  }

----
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] Seriously off-topic question...

[<her...@ru...>]

Hello! I'm really sorry if this question bothers you in any way, but it
seems this
is the only place I can ask it and actually receive a reasonable answer.

Is there any way I can calculate the area of a triangle defined by his
vertices
(x1,y1) - (x2,y2) - (x3,y3) WITHOUT the use of SQRT() in any part of the
formula?

Thanks in advance for your answer!

- Heriberto Delgado
  (her...@ru...)

RE: [Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missin g GLX extensions)

[Karl S. <ksc...@rs...>]

> > Another problem is
> > 
> > warning C4003: not enough actual parameters for macro
> > 'ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL'
> > 
> > which is caused by
> > 
> > #define ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, retval)       \
> > do {                                                            \
> >    if (ctx->Driver.CurrentExecPrimitive != GL_POLYGON+1) {      \
> >       _mesa_error( ctx, GL_INVALID_OPERATION, "begin/end" );    \
> >       return retval;                                            \
> >    }                                                            \
> > } while (0)
> > 
> > #define ASSERT_OUTSIDE_BEGIN_END(ctx) \
> >    ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx,)
> > 
> > in mtypes.h.
> > 
> > I think that the code is expanding to what we want, but is 
> just generating a
> > warning.  If we're sure that this is OK, then
> > 
> > #    pragma warning( disable : 4003 ) /* not enough actual 
> parameters for
> > macro */
> > 
> > may be a good addition to glheader.h (under the MESA_MINWARN group)
> 
> 
> The pragma might hide other, legitimate problems.
> 
> I'd rather just see the macro changed:
> 
> #define ASSERT_OUTSIDE_BEGIN_END(ctx)
> do {                                                            \
>    if (ctx->Driver.CurrentExecPrimitive != GL_POLYGON+1) {      \
>       _mesa_error( ctx, GL_INVALID_OPERATION, "begin/end" );    \
>       return;                                                   \
>    }                                                            \
> } while (0)
> 
> -Brian
>

Right.  Good point.  There's another instance of the same sort of thing in
dlist.h.
 

Re: [Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

Brian Paul wrote:
> 
> Karl Schultz wrote:
> >
> > > -----Original Message-----
> > > From: Sven M. Hallberg [mailto:pe...@gm...]
> > > Sent: Wednesday, March 21, 2001 9:37 AM
> > > To: Dirk Reiners
> > > Cc: Brian Paul; RC; mes...@li...
> > > Subject: [Mesa3d-dev] Re: [Mesa3d-users] configure problem
> > > (was Missing
> > > GLX extensions)
> >
> > snip
> >
> > > > > Well, if the compiler doesn't support the feature the
> > > only way would be
> > > > to use
> > > > > some sort of preprocessor kludge or hard-code the
> > > function names. Both
> > > > options
> > > > > seem kind of hard to accept. I'd say we check for the
> > > feature and in
> > > > case it's
> > > > > not available #define __FUNCTION__ to something sensable
> > > expressing the
> > > > lack.
> > > >
> > > > It does support __FILE__ and __LINE__, maybe using these
> > > would be better
> > > > than not having any indications of the problem happened.
> > >
> >
> > __FUNCTION__ is a problem for Windows as well.
> >
> > It would be nice to have
> >
> > #if defined(VMS) || defined(WIN32)
> > #define __FUNCTION__
> > #endif
> >
> > in texutil_tmp.h
> 
> Better yet:
> 
> #ifndef __FUNCTION__
> #define __FUNCTION__ "<some function>"
> #endif

I don't thing __FUNCTION__ is defined outside of functions, even in gcc.  

As much as I like and value __FUNCTION__ for working with templates, I'm
tempted to say we shouldn't allow it into CVS.

Keith

Re: [Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

Karl Schultz wrote:
> 
> > -----Original Message-----
> > From: Sven M. Hallberg [mailto:pe...@gm...]
> > Sent: Wednesday, March 21, 2001 9:37 AM
> > To: Dirk Reiners
> > Cc: Brian Paul; RC; mes...@li...
> > Subject: [Mesa3d-dev] Re: [Mesa3d-users] configure problem
> > (was Missing
> > GLX extensions)
> 
> snip
> 
> > > > Well, if the compiler doesn't support the feature the
> > only way would be
> > > to use
> > > > some sort of preprocessor kludge or hard-code the
> > function names. Both
> > > options
> > > > seem kind of hard to accept. I'd say we check for the
> > feature and in
> > > case it's
> > > > not available #define __FUNCTION__ to something sensable
> > expressing the
> > > lack.
> > >
> > > It does support __FILE__ and __LINE__, maybe using these
> > would be better
> > > than not having any indications of the problem happened.
> >
> 
> __FUNCTION__ is a problem for Windows as well.
> 
> It would be nice to have
> 
> #if defined(VMS) || defined(WIN32)
> #define __FUNCTION__
> #endif
> 
> in texutil_tmp.h

Better yet:

#ifndef __FUNCTION__
#define __FUNCTION__ "<some function>"
#endif



> Another problem is
> 
> warning C4003: not enough actual parameters for macro
> 'ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL'
> 
> which is caused by
> 
> #define ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, retval)       \
> do {                                                            \
>    if (ctx->Driver.CurrentExecPrimitive != GL_POLYGON+1) {      \
>       _mesa_error( ctx, GL_INVALID_OPERATION, "begin/end" );    \
>       return retval;                                            \
>    }                                                            \
> } while (0)
> 
> #define ASSERT_OUTSIDE_BEGIN_END(ctx) \
>    ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx,)
> 
> in mtypes.h.
> 
> I think that the code is expanding to what we want, but is just generating a
> warning.  If we're sure that this is OK, then
> 
> #    pragma warning( disable : 4003 ) /* not enough actual parameters for
> macro */
> 
> may be a good addition to glheader.h (under the MESA_MINWARN group)


The pragma might hide other, legitimate problems.

I'd rather just see the macro changed:

#define ASSERT_OUTSIDE_BEGIN_END(ctx)
do {                                                            \
   if (ctx->Driver.CurrentExecPrimitive != GL_POLYGON+1) {      \
      _mesa_error( ctx, GL_INVALID_OPERATION, "begin/end" );    \
      return;                                                   \
   }                                                            \
} while (0)

-Brian

Re: [Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missing GLX extensions)

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

Karl Schultz wrote:
> 
> __FUNCTION__ is a problem for Windows as well.
> 
> It would be nice to have
> 
> #if defined(VMS) || defined(WIN32)
> #define __FUNCTION__
> #endif
> 
> in texutil_tmp.h

Sorry, that's my fault.  I'm too used to gcc...

> Another problem is
> 
> warning C4003: not enough actual parameters for macro
> 'ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL'
> 
> which is caused by
> 
> #define ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, retval)       \
> do {                                                            \
>    if (ctx->Driver.CurrentExecPrimitive != GL_POLYGON+1) {      \
>       _mesa_error( ctx, GL_INVALID_OPERATION, "begin/end" );    \
>       return retval;                                            \
>    }                                                            \
> } while (0)
> 
> #define ASSERT_OUTSIDE_BEGIN_END(ctx) \
>    ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx,)
> 
> in mtypes.h.
> 
> I think that the code is expanding to what we want, but is just generating a
> warning.  If we're sure that this is OK, then
> 
> #    pragma warning( disable : 4003 ) /* not enough actual parameters for
> macro */
> 
> may be a good addition to glheader.h (under the MESA_MINWARN group)

I have new and improved win32 makefiles (in fact, a general cleanup of
the old makefiles for DOS, win32 and so on) sitting on my Win2000
partition.  I've fixed this as part of that, so next time I boot into
that I can commit this.  No timeframe for that, of course...

-- Gareth

RE: [Mesa3d-dev] Re: [Mesa3d-users] configure problem (was Missin g GLX extensions)

[Karl S. <ksc...@rs...>]

> -----Original Message-----
> From: Sven M. Hallberg [mailto:pe...@gm...]
> Sent: Wednesday, March 21, 2001 9:37 AM
> To: Dirk Reiners
> Cc: Brian Paul; RC; mes...@li...
> Subject: [Mesa3d-dev] Re: [Mesa3d-users] configure problem 
> (was Missing
> GLX extensions)

snip
 
> > > Well, if the compiler doesn't support the feature the 
> only way would be
> > to use
> > > some sort of preprocessor kludge or hard-code the 
> function names. Both
> > options
> > > seem kind of hard to accept. I'd say we check for the 
> feature and in
> > case it's
> > > not available #define __FUNCTION__ to something sensable 
> expressing the
> > lack.
> > 
> > It does support __FILE__ and __LINE__, maybe using these 
> would be better
> > than not having any indications of the problem happened.
> 

__FUNCTION__ is a problem for Windows as well.

It would be nice to have

#if defined(VMS) || defined(WIN32)
#define __FUNCTION__
#endif

in texutil_tmp.h


Another problem is

warning C4003: not enough actual parameters for macro
'ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL'

which is caused by

#define ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, retval)	\
do {								\
   if (ctx->Driver.CurrentExecPrimitive != GL_POLYGON+1) {	\
      _mesa_error( ctx, GL_INVALID_OPERATION, "begin/end" );	\
      return retval;						\
   }								\
} while (0)

#define ASSERT_OUTSIDE_BEGIN_END(ctx) \
   ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx,)

in mtypes.h.

I think that the code is expanding to what we want, but is just generating a
warning.  If we're sure that this is OK, then

#    pragma warning( disable : 4003 ) /* not enough actual parameters for
macro */

may be a good addition to glheader.h (under the MESA_MINWARN group)

Karl