On Sat, Aug 26, 2017 at 3:49 AM, Karol Herbst <[email protected]> wrote: > On Sat, Aug 26, 2017 at 3:36 AM, Ilia Mirkin <[email protected]> wrote: >> On Fri, Aug 25, 2017 at 8:23 PM, Karol Herbst <[email protected]> wrote: >>> On Sat, Aug 26, 2017 at 1:38 AM, Ilia Mirkin <[email protected]> wrote: >>>> On Fri, Aug 25, 2017 at 7:37 PM, Karol Herbst <[email protected]> >>>> wrote: >>>>> On Sat, Aug 26, 2017 at 1:30 AM, Ilia Mirkin <[email protected]> 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.
A driver that leaves the value uninitialized is a broken driver. st/mesa does not paper over brokenness. If it had, you'd never have noticed this issue in the first place, since it was valgrind that alerted you to it. -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
