Commen=
t # 13
on bug 73528<=
/a>
from Michel D=C3=A4nzer
(In reply to comment #9=
)
> I shall also test R600_LLVM=3D0. Do I just set t=
hat as a variable in the same
> console before running the SL process, or is it a compile parameter?
The former, but make sure it's actually visible in the SL process, either by
exporting it or just prepending it on the SL command line.
> I wouldn't even know where to begin bisecting in=
such an ocean of commits,
> [...]
As I said before, the information in your original report is enough to get =
the
bisection started:
git bisect bad 2dc35a619c50139d07ad96fc4dfe456e5811c84e
git bisect good mesa-9.2.3
After that, git bisect will isolate the change introducing the problem after
the minimum number of tests required, which is about a dozen (roughly the
logarithm to the base of 2 of the number of commits between the commits abo=
ve).
At this point, there's no way to make progress on this bug without someone =
who
can reproduce the problem and investigate or at least bisect it. It's up to=
you
if you want to look for someone else who fits the bill, or just bisect
yourself.
> I also compile latest GIT Mesa with latest libdr=
m from GIT. [...] Still, I
> use the free Radeon driver and X11 version provided by openSUSE 13.1. =
Could
> there be an incompatibility there?
That's unlikely, especially since Mesa 9.2.3 still works fine?
> No, I can't risk testing a newer driver or X11 t=
han my distribution offers,
> as this is my desktop and I could break it.
FYI, it's possible to test newer versions of all components without affecti=
ng
the system installed ones. But so far everything points to this being a Mesa
bug.