On Mon, Jun 24, 2019 at 11:41:55AM -0700, Eric Anholt wrote: > Elie Tournier <tournier.e...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
