[Mesa-dev] renderdoc-traces: like shader-db for runtime
Eero Tamminen
eero.t.tamminen at intel.com
Mon Jun 24 16:20:50 UTC 2019
Hi,
On 20.6.2019 22.26, Eric Anholt wrote:
> Hey folks, I wanted to show you this follow-on to shader-db I've been
> working on:
>
> https://gitlab.freedesktop.org/anholt/renderdoc-traces
>
> For x86 development I've got a collection of ad-hoc scripts to capture
> FPS numbers from various moderately interesting open source apps so I
> could compare-perf them. I was only looking at specific apps when they
> seemed relevant, so it would be easy to miss regressions.
>
> Starting work on freedreno, one of the first questions I ran into was
> "does this change to the command stream make the driver faster?". I
> don't have my old set of apps on my debian ARM systems, and even less so
> for Chrome OS. Ultimately, users will be judging us based on web
> browser and android app performance, not whatever I've got laying around
> on my debian system. And, I'd love to fix that "I ignore apps unless I
> think of them" thing.
>
> So, I've used renderdoc to capture some traces from Android apps. With
> an unlocked phone, it's pretty easy. Tossing those in a repo (not
> shared here), I can then run driver changes past them to see what
> happens. See
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1134 for some
> results.
>
> Where is this repo going from here?
>
> - I add a runner for doing frame-to-frame consistency tests. We could
> catch UB in a lot of circumstances by replaying a few times and making
> sure that results are consistent. Comparing frames between drivers
> might also be interesting, though for that you would need human
> validation since pixel values and pixels lit will change on many
> shader optimization changes.
When bisecting, ezBench[1] lists all perf and rendering changes, and
provides visual diff for *all* the rendering changes. Without latter,
something like this would have been really hard to notice & bisect:
https://bugs.freedesktop.org/show_bug.cgi?id=103197
Or something like this in a moving part of a long benchmark:
https://bugs.freedesktop.org/attachment.cgi?id=134878
https://bugs.freedesktop.org/attachment.cgi?id=134879
As to providing info on how likely driver is to be rendering something
wrong / differently instead of differences being just due to accuracy /
calculations order... Maybe something like PSNR would be useful:
https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio
?
- Eero
[1] https://github.com/freedesktop/ezbench
> - Need to collect more workloads for the public repo:
>
> - I've tried to capture webgl on Chrome and Firefox on Linux with no
> luck. WebGL on ff is supposed to work under apitrace, maybe I could
> do that and then replay on top of renderdoc to capture.
>
> - 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.
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list