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

Ilia Mirkin imirkin at alum.mit.edu
Sat Aug 26 14:14:11 UTC 2017


On Sat, Aug 26, 2017 at 3:49 AM, Karol Herbst <karolherbst at gmail.com> wrote:
> 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.

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


More information about the mesa-dev mailing list