Hi, Michel,
It doesn't seem to be a -fno-strict-aliasing issue. If I compile
r200_span.c "-O2 -fno-strict-aliasing", I still see the non-50%-gray
blend (e.g. 98A5AF instead of 7F7F7F). But if I compile it "-O2
-fno-regmove" I se the nice 50%-gray blend in the test program.
The default Debian compilation seems to be "-O2" (implicitly
-fstrict-aliasing...) vs default Mesa one of just "-O". According to
the debian changelog, it looks like in 6.5.2-1 there was a change in
the optimization flags for the DRI modules...
Note that I still haven't been able to reproduce the original banding
problem via my home-made builds, only a different blending error, so
this all might be a bit tangential to the original problem?
Thanks,
Dan
On 5/19/07, Michel Dänzer <[EMAIL PROTECTED]> wrote:
On Sat, 2007-05-19 at 00:50 -0400, Dan Torop wrote:
>
> > Please try verifying the indication that it's a Debian specific issue.
> > E.g., does building the patched Debian source tree the same way as you
> > built the upstream tree produce a working or defect r200_dri.so? Are the
> > same compiler flags used? ...
>
> If I build from the patched Debian source tree as I would from the upstream
tree
> ("make linux-dri-x86") the test program works properly. If I use a
> debian-specific
> config ("make debian-dri-i386" or debian/rules), the test program fails,
> but in a different way from the failure I reported before (rather than
> seeing banding
> in the output square, I see an non-50%-gray square whose color fluctuates over
> X server restarts, e.g. #98A5AF then #98A57F, etc.).
>
> The debian-specific config uses -O2 instead of -O. In fact, it turns
> out that everything
> works fine with the debian-dri-i386 if I compile everything at -O2 except for
> src/mesa/drivers/dri/r200/r200_span.c which must be compiled with the
> -fno-regmove
> flag in order to work properly.
Did you use -fno-strict-aliasing along with -O2? The Mesa codebase is
known not to be strict aliasing safe.
> None of these builds have replicated the banding I saw with the debian
binaries.
>
> Incidentally, I don't actually need to restart the X server to
> differentiate between
> working and defective libraries, the failure seems dependent on the version of
> r200_dri.so loaded when I execute the test program, and not at all
> dependent on the
> version of r200_dri.so loaded on X server startup (even if the two don't
match).
Yes, with direct rendering, the *_dri.so is loaded by the application
process.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
