[Mesa-dev] Perfetto CPU/GPU tracing

[Lionel Landwerlin]

On 14/02/2021 00:47, Rob Clark wrote:
> On Sat, Feb 13, 2021 at 12:52 PM Lionel Landwerlin
> <lionel.g.landwerlin at intel.com> wrote:
>> On 13/02/2021 18:52, Rob Clark wrote:
>>> On Sat, Feb 13, 2021 at 12:04 AM Lionel Landwerlin
>>> <lionel.g.landwerlin at intel.com> wrote:
>>>> On 13/02/2021 04:20, Rob Clark wrote:
>>>>> On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin
>>>>> <lionel.g.landwerlin at intel.com> wrote:
>>>>>> On 13/02/2021 03:38, Rob Clark wrote:
>>>>>>> On Fri, Feb 12, 2021 at 5:08 PM Lionel Landwerlin
>>>>>>> <lionel.g.landwerlin at intel.com> wrote:
>>>>>>>> We're kind of in the same boat for Intel.
>>>>>>>>
>>>>>>>> Access to GPU perf counters is exclusive to a single process if you want
>>>>>>>> to build a timeline of the work (because preemption etc...).
>>>>>>> ugg, does that mean extensions like AMD_performance_monitor doesn't
>>>>>>> actually work on intel?
>>>>>> It work,s but only a single app can use it at a time.
>>>>>>
>>>>> I see.. on the freedreno side we haven't really gone down the
>>>>> preemption route yet, but we have a way to hook in some safe/restore
>>>>> cmdstream
>>>> That's why I think, for Intel HW, something like gfx-pps is probably
>>>> best to pull out all the data on a timeline for the entire system.
>>>>
>>>> Then the drivers could just provide timestamp on the timeline to
>>>> annotate it.
>>>>
>>> Looking at gfx-pps, my question is why is this not part of the mesa
>>> tree?  That way I could use it for freedreno (either as stand-alone
>>> process or part of driver) without duplicating all the perfcntr
>>> tables, and information about different variants of a given generation
>>> needed to interpret the raw counters into something useful for a
>>> human.
>>>
>>> Pulling gfx-pps into mesa seems like a sensible way forward.
>>>
>>> BR,
>>> -R
>> Yeah, I guess it depends on how your stack looks.
>>
>> If the counters cover more than 3d and you have video drivers out of the
>> mesa tree, it might make sense to have it somewhere else.
> Pulling intel video drivers into mesa and bringing some sanity to that
> side of things would make more than a few people happy (but I digress
> ;-))
>
> Until then, exporting a library from the mesa build might be an
> option?  And possibly something like that would work for virgl host
> side stuff as well?


For Intel, we have a small library in IGT [1], it's not big and most of 
that logic also exists in src/intel/perf [2] too.

So definitely possible.

Might also be a good occasion to try to make a common sublibrary for 
Intel drivers so we don't carry the statically link code from 
src/intel/perf in each driver.


-Lionel


>
>> Anyway I didn't want to sound negative, having a daemon like gfx-pps
>> thing in mesa to report system wide counters works for me :)
> yeah, I think having it in the mesa tree is good for code-reuse (from
> my experience, pulling external freedreno related tools into mesa
> turned out to be a good thing)
>
> At some point, whether the collection is in-process or not could just
> be an implementation detail
>
> BR,
> -R
>
>> Then we can look into how to have each intel driver add annotation on
>> the timeline.
>>
>>
>> -Lionel
>>

[1] : 
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/lib/i915/perf.c

[2] : https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/src/intel/perf