Patches to glretrace to add support for looping arbitrary frames

[Jon Ashburn]

Jose:

I will look into making a LoopParser class to handle the various looping 
logic.
Regards,
Jon

On 05/27/2014 10:35 AM, José Fonseca wrote:
> Jon,
>
> 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.
>
> 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:
>
>  // Parser interface
>  class BaseParser {
>     virtual  parse_call() = 0;
>   };
>
>   // Concrete parser
>   class Parser :  public BaseParser {
>   }
>
>   // Decorator for parser which loops
>   class LoopParser : public BaseParser  {
>   }
>
> 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.
>
> You could even have an hierrachy on top of LoopParser: 
> LastFrameLoopParser, CallRangeLoopParser, FrameRangeLoopParser, etc.
>
> Jose
>
>
>
> On Tue, Apr 22, 2014 at 7:53 PM, Jon Ashburn <jon at lunarg.com 
> <mailto:jon at lunarg.com>> wrote:
>
>     glretrace has ability to loop the last frame of a trace
>     continuosly. These
>     two patches improve upon this feature in several ways.  For
>     analysis of
>     the driver/GPU performance  from a captured trace the existing
>     looping can be
>     improved. Firstly, statistics  of the looping  performance should
>     be logged,
>     in addition to the total retrace statistics which include non
>     looping frames.
>     Secondly, the  looping should be generalized for N iterations and
>     any arbitrary
>     range of frames or API call numbers.  Thirdly, time spent in
>     apitrace  parsing
>     and executing calls  should be minimized so any driver or GPU
>     bottlenecks  are
>     not masked by glretrace looping replay time.
>
>     To achieve these improvements, these features are added to
>     glretrace by these
>     patches:
>
>     Add  a numeric parameter to the --loop option which is the number
>     of times to
>     loop.  Zero is continuous looping, default is 1.
>
>     Add --framerange  option that allows an arbitray range of frames
>     to be looped
>     and log the time spent in the framerange looping.
>
>     Add --callrange option that allows an arbitrary range of call
>     numbers to be
>     looped and log the time spent in the callrange looping.
>      Framerange and callrange
>     are mutually exclusive options. --loop=N specifies the number of
>     times to loop
>     the range.  The replay ends after the looping is finished.
>
>     When executing a looping replay (non-continuos  and iterations !=
>     1)  first
>     save the parsed API calls.  Thus,  no need to reparse  the calls
>     on every
>     iteration of a loop.  This vastly improves the execution time  of
>     glretrace.
>     The looping replay performance, in many cases now matches the
>     performance for
>     the frames of interest from the original app/benchmark prior to
>     capture.  This
>     makes glretrace a very useful performance analysis tool  and also
>     performance
>     regression tool.
>     _______________________________________________
>     apitrace mailing list
>     apitrace at lists.freedesktop.org <mailto:apitrace at lists.freedesktop.org>
>     http://lists.freedesktop.org/mailman/listinfo/apitrace
>
>

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