[Mesa-dev] renderdoc-traces: like shader-db for runtime

[Rob Clark]

On Mon, Jun 24, 2019 at 11:48 AM Eric Anholt <eric at anholt.net> wrote:
>
> Rob Clark <robdclark at gmail.com> writes:
>
> > On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt <eric at anholt.net> wrote:
> >
> > (tbh I've not really played w/ renderdoc yet.. I should probably do so..)
> >
> >>   - Mozilla folks tell me that firefox's WebRender display lists can be
> >>     captured in browser and then replayed from the WR repo under
> >>     apitrace or rendredoc.
> >>
> >>   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
> >>     it wouldn't play the demo under renderdoc.
> >>
> >>   Do you have some apps that should be represented here?
> >>
> >> - Add microbenchmarks?  Looks like it would be pretty easy to grab
> >>   piglit drawoverhead results, not using renderdoc.  Capturing from
> >>   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
> >>   excited about (Do we do different configs in those apps?  Then we need
> >>   config infrastructure.  Ugh).
> >>
> >> - I should probably add an estimate of "does this overall improve or
> >>   hurt perf?"  Yay doing more stats.
> >>
> >> - I'd love to drop scipy.  I only need it for stats.t.ppf, but it
> >>   prevents me from running run.py directly on my targets.
> >
> > thoughts about adding amd_perfcntr/etc support?  I guess some of the
> > perfcntrs we have perhaps want some post-processing to turn into
> > usuable numbers, and plenty of them we don't know much about what they
> > are other than the name.  But some of them are easy enough to
> > understand (like # of fs ALU cycles, etc), and being able to compare
> > that before/after shader optimizations seems useful.
>
> I'm not coming up with a good usecase for that, myself -- shader-db
> gives me a reasonable proxy for ALU cycles, and we've got wall time for
> a frame from this new tool, so perf counters would let me
> measure... maybe something like cycles spent in shader including stalls
> (think an optimization like GCM where shader-db analysis is unsuitable)
> but avoiding the rest of the noise introduced from CPU side costs and
> scheduling of jobs onto the GPU?

I suspect it would be useful in cases where we shift one bottleneck to another..

anyways, I think it is something that could be done generically (ie.
cmdline arg to ask for various counters by name).. that isn't to say
that this isn't already pretty useful as-is, but I guess adding
perfcntrs is probably something I'd do sooner or later..

BR,
-R

> Running my current perf analysis overnight feels a lot easier than
> trying to add configuration to capture specific GPU perf counters to the
> tool.  :)
>
> > Also, it would be nice to have a way to extract "slow frames" somehow
> > (maybe out of scope for this tool, but related?).. ie. when framerate
> > suddenly drops, those are the frames we probably want to look at more
> > closely..
>
> Renderdoc lets you capture a series of frames, so I guess you could do
> that and pick out your slow one?