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