On 14/02/2021 00:47, Rob Clark wrote:
On Sat, Feb 13, 2021 at 12:52 PM Lionel Landwerlin
<lionel.g.landwer...@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.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
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
