Some textures are not rendering correctly in apitrace
Benjamin Bellec
b.bellec at gmail.com
Tue Nov 4 11:47:46 PST 2014
OK I will try right now.
2014-11-04 20:35 GMT+01:00 José Fonseca <jose.r.fonseca at gmail.com>:
>
>
> On Tue, Nov 4, 2014 at 6:56 PM, José Fonseca <jose.r.fonseca at gmail.com>
> wrote:
>
>>
>>
>> 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.
>>
>
> If this is indeed the problem, then the attached patch might help. Could
> you please apply the patch, re-build apitrace, and re-capture the trace
> with ss3?
>
> Jose
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20141104/19a4b8ab/attachment.html>
More information about the apitrace
mailing list