Some textures are not rendering correctly in apitrace

[Benjamin Bellec]

OK thanks, tell me if you want I test something.

Anyway, I caught another trace, where here the main weapon is correctly
rendered in apitrace but the another one (a detonator) not really : it's
moves like gelatin. Hope that helps.

Trace :
https://drive.google.com/file/d/0B7D2Y0QXFND2N19uNTB4TXhlRFk/view?usp=sharing
(150 MB)
md5sum : 3e12097effaf545d2bccba522345b64f

Regards.

2014-11-04 19:56 GMT+01:00 José Fonseca <jose.r.fonseca at gmail.com>:

>
>
> On Mon, Nov 3, 2014 at 9:06 PM, Benjamin Bellec <b.bellec at gmail.com>
> wrote:
>
>> Here is an example trace, if somebody wants to give a look :
>>
>> https://drive.google.com/file/d/0B7D2Y0QXFND2ODF2QlExc2w0Y0U/view?usp=sharing
>>
>>
> Thanks.  I took a quick look.
>
> This call draws the weapon's geometry to depth-map
>
>   329154 glDrawRangeElements(mode = GL_TRIANGLES, start = 0, end = 7581,
> count = 18585, type = GL_UNSIGNED_SHORT, indices = NULL)
>
> and then later on on this call the weapon is lit:
>
>   333371 glDrawRangeElements(mode = GL_TRIANGLES, start = 0, end = 7581,
> count = 18585, type = GL_UNSIGNED_SHORT, indices = NULL)
>
> In both cases I'm seeing weird geometry on the weapon.
>
> AFAICT, all the state being bound on this calls is pretty standard stuff
> -- nothing that could cause problems to apitrace.
>
>
> The only explanation I can think of so far is that some
> glMapBufferRange(GL_MAP_WRITE_BIT) done by the application are in
> write-combining memory, and that when apitrace's wrapper tries to copy that
> memory into the trace file it doesn't get the data that the application
> wrote, but something wrong, which then gets baked into the trace file,
> appearing on subsequent replays.  I'll need to investigate this more.
>
>
> Jose
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20141104/d6838c7b/attachment.html>