[Mesa-dev] renderdoc-traces: like shader-db for runtime
eric at anholt.net
Mon Jun 24 18:47:58 UTC 2019
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?
Running my current perf analysis overnight feels a lot easier than
trying to add configuration to capture specific GPU perf counters to the
> 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
Renderdoc lets you capture a series of frames, so I guess you could do
that and pick out your slow one?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the mesa-dev