On Sat, Feb 13, 2021 at 12:04 AM Lionel Landwerlin <lionel.g.landwer...@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.landwer...@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.landwer...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
