<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 6:22 PM, Benjamin Bellec <span dir="ltr"><<a href="mailto:b.bellec@gmail.com" target="_blank">b.bellec@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Yes I confirm that the weapons are *always* correctly rendered while tracing. The corruption only appears in the apitrace.<br></div></div></blockquote><div><br></div><div>Wow. This is one of the weirdest things i've seen.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Anyway thanks for this explanation.<br>So, do you think a hardware (physical) problem can be the origin of this ?<br></div><div>Or more probably a software one ? </div></div></blockquote><div><br></div><div><br></div><div><br></div><div><br></div><div>Please do two more experiments:</div><div><br></div><div>1. Undo any previous changes to apitrace tree, apply the attached patch zlib.patch and see if it helps. </div><div><br></div><div>   This will force apitrace to compress with zlib instead of snappy, so eliminate the chance that the bug is not on glMapBufferRange but inside snappy somehow.</div><div><br></div><div></div><div>2. Ditto with pin-thread-on-cpu.patch.<br></div><div><br></div><div>  If this is a problem due to stale CPU cache this might help.</div><div><br></div><div>3. Ditto with glfinish.patch</div><div><br></div><div>   If GPU is the one scribbling over then this call should make the issue either never happen or happen all the time.</div><div><br></div><div>4. try tracing the replay of the good ss3_correct_without_patch.trace like<br></div><div><div><br></div><div>  ./apitrace trace ./glretrace -b ss3_correct_without_patch.trace</div><div><br></div><div>a few times, and check whether the replays are as good as ss3_correct_without_patch.trace, or if they regress some times, like the real app does.  This might help determine whether the ss3 application is doing something special, or not.</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Because I was surprised, indeed, I have another problematic bug that occurs, aparently with glMapBufferRange() too, see <a href="https://bugs.freedesktop.org/show_bug.cgi?id=77596" target="_blank">BUGZILLA #77596 </a>particularly my #7 comments. Maybe this is just coincidence. I'm not an OpenGL developper so I don't know where the glMapBufferRange's "lenght" parameter come from ? (from the game or from the OpenGL driver itself).<br></div></div></blockquote><div><br></div><div>It's hard to say whether it's related. glMapBufferRange's length parameter is specified by the app, but the app could be computing that value based on glGet* queries done to the OpenGL driver, and some times there are bugs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>To sum up, what do you think I should do now ? Fill a bug against the OpenGL driver ?<br></div></div><div><div><div class="gmail_extra"><br></div></div></div></blockquote><div> </div><div>Let's see if the above experiments help narrow this further.</div><div><br></div><div><br></div><div>I really hate when apitrace is not able to capture something properly -- it's like most basic of basic functionality -- everything else (replay, UI, state dumping) can be fixed improved after the fact, but if the trace itself can't be trusted then that's showstopper.  So fingers crossed..</div><div><br></div><div><br></div><div>Jose</div><div> </div></div></div></div>