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

[Elie Tournier]

On Mon, Jun 24, 2019 at 11:41:55AM -0700, Eric Anholt wrote:
> Elie Tournier <tournier.elie at gmail.com> writes:
> 
> > Hi there,
> >
> > Great topic. For the past few days, I was looking at a CI for Mesa:
> > https://gitlab.freedesktop.org/hopetech/tracie
> > OK, it's in a very very alpha stage. ;)
> 
> I did one of those things using apitrace diff-images in piglit:
> 
> https://gitlab.freedesktop.org/mesa/piglit/tree/master/tests/apitrace
> 
> https://github.com/anholt/trace-db
> 
> It was bad.  diff-images is too picky and you end up needing to bless
> new images constantly.  I have decided to not pursue this line of
> testing any further because it was so unproductive.
For now, my plan is to run the CI only once a week.
So efficiency is not my top priority right now. But it will at some point.

I'm trying to figure out which tools is the best for this job:
Correctness *and* perf testing.

> 
> What I *am* interested in trying with traces for correctness testing is
> using a single driver to replay trace keyframes multiple times and make
> sure the image is invariant.  This could catch a large class of UB in
> real world applications without needing continuous human intervention.
So what's happening if an object is not render in all frame?
> 
> > @eric Out of curiosity, did you looked at apitrace or did you go
> > straight with renderdoc?
> 
> Since I was only looking at perf, I didn't use apitrace (I'd tried to
> use it for perf in the past and it was absolutely dominated by trace
> loading).  frameretrace would have made apitrace interesting to use for
> this, but José blocked merging that.  That makes apitrace pretty dead
> from my perspective.
> 
> Also, renderdoc's android capture is really nice to use.
Thanks for your input.