[Mesa-dev] [PATCH] st/query: init result data with 0

Karol Herbst karolherbst at gmail.com
Sat Aug 26 07:49:03 UTC 2017


On Sat, Aug 26, 2017 at 3:36 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Fri, Aug 25, 2017 at 8:23 PM, Karol Herbst <karolherbst at gmail.com> wrote:
>> On Sat, Aug 26, 2017 at 1:38 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Fri, Aug 25, 2017 at 7:37 PM, Karol Herbst <karolherbst at gmail.com> wrote:
>>>> On Sat, Aug 26, 2017 at 1:30 AM, Ilia Mirkin <imirkin at 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


More information about the mesa-dev mailing list