Some textures are not rendering correctly in apitrace

[José Fonseca]

On Tue, Nov 4, 2014 at 9:09 PM, Benjamin Bellec <b.bellec at gmail.com> wrote:

> Unfortunatly it doesn't help.
> That said, I just tried many times, and sometimes everything is fine...
> (even without your patch). Here is an example trace when everything is fine
> :
>
> https://drive.google.com/file/d/0B7D2Y0QXFND2c3pzRi1HTGRFVDg/view?usp=sharing
> (152 MB)
> md5sum : 35bef1e4519ba70cf083daf46c8670ce
>
>
Thanks for the additional traces. With them I have undeniable proof that
the corruption in the first weapon comes from apitrace reading bad data
from the glMapBufferRange() of the vertex buffer:

184065 glMapBufferRange(target = GL_ARRAY_BUFFER, offset = 0, length =
1538560, access = GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_RANGE_BIT) =
0xdedce000
184066 memcpy(dest = 0xdedce000, src = blob(1538560), n = 1538560)
184067 glUnmapBuffer(target = GL_ARRAY_BUFFER) = GL_TRUE

I extracted the vertex buffer blob from the three traces. The data from
ss3_weird.trace is busted, while data from ss3_weird2.trace and
ss3_correct_without_patch.trace are identical byte by byte.  And if I hack
glretrace to use the good vertex data the weapon is rendered fine.

Why apitrace gets bad data I don't know.   Here's the wdiff of the hexdump
of a good data and bad data:

0016870: 61a0303d ccf112bf 64fa6fbc 67672c3d
0016880: ba6a12bf 71a0f23b 67621a3d ccf112bf
0016890: 90896f3c 67672c3d ba6a12bf a44973bc
00168a0: 67024f3d ccf112bf 19888abc 67024f3d
00168b0: ba6a12bf 3748523c 61a0303d ccf112bf
00168c0: 50508a3c 67024f3d ba6a12bf e1b952bc
00168d0: 87646d3d ccf112bf 64fa6fbc 9c9d713d
00168e0: ba6a12bf [-d0d8723c-] {+228a293c+} 67024f3d ccf112bf
00168f0: 90896f3c [-9c9d713d-] {+228a293d+} ba6a12bf 3748523c
0016900: 87646d3d ccf112bf 2c340a3c 6c79853d
0016910: ba6a12bf [-71a0f23b-] {+228a293b+} 41d1813d ccf112bf
0016920: 409562b7 [-5c1c8a3d-] {+228a293d+} ba6a12bf 4382f3bb
0016930: 41d1813d [-ccf112bf-] {+228a29bf+} e6a20abc 6c79853d
0016940: ba6a12bf 409562b7 54e3853d ccf112bf
0016950: 4f5f0bbc [-f2b3313e-] {+228a293e+} 4eb47bbe d7b246bc
0016960: bbb4313e [-91b47bbe-] {+228a29be+} 0fdac4bb 29b3313e
0016970: 0bb47bbe [-749fb7bc-] {+228a29bc+} 3f1f153e 01f77cbe
0016980: 749fb7bc 5ed6143e 7c7d7dbe 5b1dcabc
0016990: 5ed6143e [-7c7d7dbe-] {+228a29be+} 3d12cabc 3f1f153e
00169a0: 01f77cbe [-0d28cabc-] {+228a29bc+} baa2143e 240d7ebe
[...]
0116880: ac5cac3d 15c8813e 568bb83d b363803e
0116890: 568bb83d [-ab4f7b3e-] {+228a293e+} ac5cac3d 8356783e
01168a0: ac5cac3d [-6f706f3e-] {+228a293e+} 568bb83d afa76c3e
01168b0: 568bb83d [-afa76c3e-] {+228a293e+} ac5cac3d 6f706f3e
01168c0: f6f5973c 318a353e f6f5973c 318a353e
01168d0: f6f5973c 1080713e f6f5973c 1080713e
01168e0: f6f5973c 2536fe3d f6f5973c 9aed903e
01168f0: f6f5973c 2536fe3d f6f5973c 9aed903e
0116900: f6f5973c fd96cb3d f6f5973c fd96cb3d

It's too many changes to be related to the write-combining buffer.

It looks like the bytes 22 8a 29 write scribbled over with a stride of
16-bytes except every 4th row.  So it actually looks like the GPU or
something else scriblling over the buffer memory mapping somehow.

Can you confirm just one detail: while you capture the trace, are weapons
always rendered OK or does it also vary?

AFAICS, I can't find any evidence of apitrace being in the wrong. But
rather your system (either the hardware or the OpenGL drivers) behaving
very weird...

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20141105/de1c623e/attachment.html>