On Sat, Aug 26, 2017 at 3:36 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Aug 25, 2017 at 8:23 PM, Karol Herbst <karolher...@gmail.com> wrote: >> On Sat, Aug 26, 2017 at 1:38 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> On Fri, Aug 25, 2017 at 7:37 PM, Karol Herbst <karolher...@gmail.com> wrote: >>>> On Sat, Aug 26, 2017 at 1:30 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>>>> Why is this necessary? If data is not initialized, then presumably >>>>> pipe->get_query_result will have returned false. >>>>> >>>> >>>> but it didn't. It might be the drivers fault (in my case nouveau) that >>>> it writes garbage or nothing into data. Where it is most likely the >>>> latter. >>> >>> Sounds like a nouveau bug then. >> >> looks like nouveau never writes to >> result->pipeline_statistics.cs_invocations, because it only writes >> into the first 10 fields leaving out this 11th one. > > Right. We don't support CS invocations. Can't say I'm entirely sure > how to implement it. And unfortunately mmt traces that involve compute > don't always decode properly. > > I don't think there's a hw counter, so you have to do something > clever. Like keep track of it in a scratch method for QBO and in a > counter on the cpu side? >
Okay, but I would handle this as a separate issue. Returning 0 for unsupported counters sounds better than returning random values and even if a driver doesn't actually write into such a value, it either means it is unsupported or it has a bug writing to it, which would be caught debugging with the other tests. We could also require the driver to do that, but I prefer to do this globally for all drivers. > -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev