Thread: [Mesa3d-dev] Mesa 3.4.1 heads-up

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I'd like to release Mesa 3.4.1 within the next week.  It'll
basically be just a bug-fix release.  Does anyone have any
outstanding work that should be included?

-Brian

Brian Paul wrote:
> 
> I'd like to release Mesa 3.4.1 within the next week.  It'll
> basically be just a bug-fix release.  Does anyone have any
> outstanding work that should be included?

I think the basic texture conversion work is done.  There needs to be
some integration into 3.5, but the initial layered framework is
complete.  I'll make sure the tdfx and Radeon drivers work fine with it
before I commit it to Mesa CVS.

How does this sound?

-- Gareth

I just submitted a problem in _mesa_clear_depth_buffer() to
the bug list, that I would like to see fixed.  Also, the
NURB surfaces seem to have a problem computing proper
normals for a view of the points on the surface.  I just
saw this one in my testBezierSurfaces program in SGL
(sgl.sourceforge.net) about 15 minutes ago, and have not had
time to characterize it better...but it is similar to a
problem I reported before the release of 3.4, that I 
thought had been fixed (but perhaps not).  I won't have
a chance to check out a CVS view in the next few days.

Brian Paul wrote:
> 
> I'd like to release Mesa 3.4.1 within the next week.  It'll
> basically be just a bug-fix release.  Does anyone have any
> outstanding work that should be included?
> 
> -Brian

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Scott McMillan wrote:
> 
> I just submitted a problem in _mesa_clear_depth_buffer() to
> the bug list, that I would like to see fixed.

I'll look into it.  Thanks.

> Also, the
> NURB surfaces seem to have a problem computing proper
> normals for a view of the points on the surface.  I just
> saw this one in my testBezierSurfaces program in SGL
> (sgl.sourceforge.net) about 15 minutes ago, and have not had
> time to characterize it better...but it is similar to a
> problem I reported before the release of 3.4, that I
> thought had been fixed (but perhaps not).  I won't have
> a chance to check out a CVS view in the next few days.

Likely a problem in Mesa's GLU library.  You might want to
use the SGI SI GLU library instead.  You can download it
from the Mesa website.  I plan to replace Mesa's GLU with
the SI GLU in the future.

-Brian

Scott McMillan wrote:
> 
> I just submitted a problem in _mesa_clear_depth_buffer() to
> the bug list, that I would like to see fixed.

Scott, is your window manager set to do opaque resizes?  I.e.
does the window constantly resize as you move the mouse?
Or, does interactive resizing use a rubberband rectangle?

-Brian

Brian Paul wrote:
> 
> Scott McMillan wrote:
> >
> > I just submitted a problem in _mesa_clear_depth_buffer() to
> > the bug list, that I would like to see fixed.
> 
> Scott, is your window manager set to do opaque resizes?  I.e.
> does the window constantly resize as you move the mouse?
> Or, does interactive resizing use a rubberband rectangle?

Nevermind.  I found the problem.  I'm sending you an updated
Mesa-3.4/src/depth.c file for you to try.  Let me know if
you still have trouble.

-Brian

Unfortunately it was one of those problems where I could
resize the window up to about 20 times before I hit the
right timing or combination that set off the error.

Having said that, however, I just resized the window
about 100 times in a row without failure.

Thanks,
scott

Brian Paul wrote:
> 
> Brian Paul wrote:
> >
> > Scott McMillan wrote:
> > >
> > > I just submitted a problem in _mesa_clear_depth_buffer() to
> > > the bug list, that I would like to see fixed.
> >
> > Scott, is your window manager set to do opaque resizes?  I.e.
> > does the window constantly resize as you move the mouse?
> > Or, does interactive resizing use a rubberband rectangle?
> 
> Nevermind.  I found the problem.  I'm sending you an updated
> Mesa-3.4/src/depth.c file for you to try.  Let me know if
> you still have trouble.
> 
> -Brian

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Brian Paul wrote:
> 
> I'd like to release Mesa 3.4.1 within the next week.  It'll
> basically be just a bug-fix release.  Does anyone have any
> outstanding work that should be included?

I'm going to hold off on the 3.4.1 release for a few more days.
I'm waiting for feedback on a couple of outstanding bugs.

-Brian

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;
}
}

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.

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

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

Thread: [Mesa3d-dev] Mesa 3.4.1 heads-up

mesa3d-dev