Some textures are not rendering correctly in apitrace

[José Fonseca]

On Wed, Nov 5, 2014 at 6:22 PM, Benjamin Bellec <b.bellec at gmail.com> wrote:

> Yes I confirm that the weapons are *always* correctly rendered while
> tracing. The corruption only appears in the apitrace.
>

Wow. This is one of the weirdest things i've seen.


> Anyway thanks for this explanation.
> So, do you think a hardware (physical) problem can be the origin of this ?
> Or more probably a software one ?
>




Please do two more experiments:

1. Undo any previous changes to apitrace tree, apply the attached
patch zlib.patch and see if it helps.

   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.

2. Ditto with pin-thread-on-cpu.patch.

  If this is a problem due to stale CPU cache this might help.

3. Ditto with glfinish.patch

   If GPU is the one scribbling over then this call should make the issue
either never happen or happen all the time.

4. try tracing the replay of the good ss3_correct_without_patch.trace like

  ./apitrace trace ./glretrace -b ss3_correct_without_patch.trace

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.

Because I was surprised, indeed, I have another problematic bug that
> occurs, aparently with glMapBufferRange() too, see BUGZILLA #77596
> <https://bugs.freedesktop.org/show_bug.cgi?id=77596>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).
>

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.


>
> To sum up, what do you think I should do now ? Fill a bug against the
> OpenGL driver ?
>
>
Let's see if the above experiments help narrow this further.


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..


Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20141105/66cee5ba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pin-thread-on-cpu.patch
Type: text/x-patch
Size: 1462 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20141105/66cee5ba/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glfinish.patch
Type: text/x-patch
Size: 534 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20141105/66cee5ba/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib.patch
Type: text/x-patch
Size: 952 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20141105/66cee5ba/attachment-0002.bin>