[PATCH] retrace: support for dumping multiple snapshots

[Tapani Pälli]

On 01/20/2017 05:02 PM, Rob Clark wrote:
> On Fri, Jan 20, 2017 at 5:24 AM, Tapani Pälli <tapani.palli at intel.com> wrote:
>> Hi;
>>
>> On 01/18/2017 01:43 AM, Rob Clark wrote:
>>>
>>> Usually if an app is using MRT, we want to dump (and diff) *all* the
>>> render targets to track down where things are going wrong.
>>>
>>> Only implemented for GLDumper, since I don't know anything about D3D.
>>>
>>> TODO maybe cmdline arg to control this?  I'm not sure, I kinda tend to
>>> think if you are using dump-images + diff-images you probably want to
>>> compare all the render targets.  Maybe even depth/stencil.
>>
>>
>> This seemed interesting idea to debug MRT so I tried this patch to trace
>> test app that utilizes MRT but I did not get many dumps as result (was
>> expecting dump of each buffer in gbuffer), just lots of files with '_0' like
>> there was only 1 attachment in use.
>>
>> I believe this is because the app does additional processing steps after
>> producing the gbuffer results and in the final render to display we do have
>> only one buffer. How should this work, when does the dump happen from GL API
>> POV? It seems likely that many games will have postprocess steps where
>> gbuffer is already 'composited'.
>
> fwiw, you probably need to use it w/ --calls "X-Y/draw".. by default
> you'll only get the dumps on frame (when the gbuffer's aren't bound as
> a MRT).

Ah yes with using 'calls' option I'm getting gbuffer contents, nice! 
This would be useful debugging feature.

Acked-by: Tapani Pälli <tapani.palli at intel.com>

> The use-case I had was dissecting a single frame's worth of draws to
> find where things started going badly.  I think I may end up needing
> to add depth/stencil buffer too.
>
> BR,
> -R
>
>
>> Thanks;
>>
>> // Tapani
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/apitrace
>