Comment=
# 3
on bug 93264<=
/a>
from Nicolai H=C3=A4hnle
Time to document some information I've gathered.
I can now confirm that Mesa has nothing to do with it. Something must have =
gone
wrong with my builds initially, sorry for having caused confusion.
I captured an apitrace for better reproducibility[0] and ran it with shader
dumps enabled and flushing after each draw call in the "interesting&qu=
ot; region.
I am going to attach the R600_DEBUG=3Dcheck_vm dump which I've cross-refere=
nced
with R600_DEBUG=3Dvm to obtain the shaders that were active during the draw=
call
(file names with prefix llvm-c0a189c.mesa-caf12bebd). I then matched the
shaders to those dumped by a run with a good version of LLVM (commit just
before the bad one, file names with prefix llvm-26ddca1.mesa-caf12bebd).
Clearly, the LLVM changes caused some significant re-ordering of the
instruction schedule, and that somehow, surprisingly, seems to be responsib=
le
for the VM faults.
Another aspect to note is that the shaders are compiled before draw call
174000, while the VM faults happen shortly after draw call 178000. This see=
ms
to suggest that the shaders alone only cause VM faults in conjunction with =
some
other state. However, the VM faults have always happened in exactly the same
point so far, so it does appear to be deterministic.
[0] The demo always causes VM faults, so I'm not going to upload the giant
trace; however, the timing varies between runs, so it's cleaner to reproduce
using a trace.