Rob Clark <robdcl...@gmail.com> writes: > On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt <e...@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 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?
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev