Mesa3D

Logged In: YES
user_id=983

OK, I've checked in your patch (with a few more casts for
the specular color interpolants). I'm closing this bug now.

Logged In: YES
user_id=961864

I think I have found the problem.
In the Triangle Rasterizer Template the span calculation
creates temporaries such as GLfloat eMaj_dr which involves a
subtraction, the first term of which is explictly cast and
the second term is not resulting in very large numbers with
xlc. By explictly casting the second term too things behave
properly again.

Logged In: YES
user_id=983

Don't worry about the ALIGN16 stuff - it's not essential.
I don't know of any places where structure member layout is
significant.
My guess is there's something wrong with smooth color
interpolation in the triangle functions or in
interpolate_colors().

Perhaps you could write a test program that renders a single
smooth-shaded triangle and see what happens. Actually,
progs/redbook/smooth.c might be worth trying.

Logged In: YES
user_id=961864

I made an aix-debug target with no optimisation and built
that. It generates the same output.

I tried to mix some code from the gcc build with the ones
from xlc to see if I could isolate the problem but that
didn't work at all, I guess there is some different
structure packing going on or something.

The only compile error I get is from
src/mesa/math/m_debug_util.h where the ALIGN16 macro isn't
implemented. Unfortunately the directive for xlc comes
between the type and the variable declaration so I redid the
macro a little and put this in, I don't know if this is
necessary, but it had no effect.

Logged In: YES
user_id=983

Thanks for the patches! I've also adapted them to the Mesa
CVS trunk for the 6.1 release.

As for the rendering errors, the first thing I'd try is to
reduce the optimization level for the C compiler.

Whether you're rendering the the Linux/NVIDIA box or to the
local off-screen X server, you're just using software
rendering and Xlib calls.