<div dir="ltr"><div><div><div><div><div><div><div><div>Jon,<br><br></div>I looked into this further, and the logic to execute the loops is too spread out, touching too many places, which will make things really hard to maintain.<br>
<br></div>I'd like to see all the logic for all sort of looping (be it infinite loop, last-frame, frame range, call-range etc) to be encapsulated in a single class, "LoopParser", which acts  as a decorator for vanilla Parsers:<br>
<br></div><div> // Parser interface<br></div><div> class BaseParser {<br>    virtual  parse_call() = 0;<br>  };<br><br></div><div>  // Concrete parser<br></div><div>  class Parser :  public BaseParser {<br>  }<br><br></div>
<div>  // Decorator for parser which loops<br></div><div>  class LoopParser : public BaseParser  {<br>  }<br><br></div>LoopParser::parse_call() would internally rewind the stream, so that the rest of retrace_main.cpp just calls parse_call() and doesn't even know if its using a LoopParser or a Parser.<br>
</div><br></div><div>You could even have an hierrachy on top of LoopParser: LastFrameLoopParser, CallRangeLoopParser, FrameRangeLoopParser, etc.<br></div><div><br>Jose<br></div><div><div><div><div><br></div></div></div></div>
</div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 7:53 PM, Jon Ashburn <span dir="ltr"><<a href="mailto:jon@lunarg.com" target="_blank">jon@lunarg.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">glretrace has ability to loop the last frame of a trace continuosly. These<br>
two patches improve upon this feature in several ways.  For analysis of<br>
the driver/GPU performance  from a captured trace the existing looping can be<br>
improved. Firstly, statistics  of the looping  performance should be logged,<br>
in addition to the total retrace statistics which include non looping frames.<br>
Secondly, the  looping should be generalized for N iterations and any arbitrary<br>
range of frames or API call numbers.  Thirdly, time spent in apitrace  parsing<br>
and executing calls  should be minimized so any driver or GPU bottlenecks  are<br>
not masked by glretrace looping replay time.<br>
<br>
To achieve these improvements, these features are added to glretrace by these<br>
patches:<br>
<br>
Add  a numeric parameter to the --loop option which is the number of times to<br>
loop.  Zero is continuous looping, default is 1.<br>
<br>
Add --framerange  option that allows an arbitray range of frames to be looped<br>
and log the time spent in the framerange looping.<br>
<br>
Add --callrange option that allows an arbitrary range of call numbers to be<br>
looped and log the time spent in the callrange looping.  Framerange and callrange<br>
are mutually exclusive options. --loop=N specifies the number of times to loop<br>
the range.  The replay ends after the looping is finished.<br>
<br>
When executing a looping replay (non-continuos  and iterations != 1)  first<br>
save the parsed API calls.  Thus,  no need to reparse  the calls on every<br>
iteration of a loop.  This vastly improves the execution time  of glretrace.<br>
The looping replay performance, in many cases now matches the performance for<br>
the frames of interest from the original app/benchmark prior to capture.  This<br>
makes glretrace a very useful performance analysis tool  and also performance<br>
regression tool.<br>
_______________________________________________<br>
apitrace mailing list<br>
<a href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
</blockquote></div><br></div>