[PATCH V3 00/23] drm/etnaviv: support performance counters
Christian Gmeiner
christian.gmeiner at gmail.com
Fri Aug 25 09:06:59 UTC 2017
In a perfect world we would be able to read GPU registers of interest
via the command stream with a 'read-register' command/package. For perf
counters it is a must to read them synchronized with the GPU to put the
values in relation to a draw command. As Vivante GPUs do not provide this
functionality we need to emulate it in software.
We need to support three different kind of perf register types:
1) normal register
This is the easierst case where we can simply read the register and we
are done.
2) debug register
We need to configure the mux register and then read the debug register value.
3) pipeline register
We need to 'iterate' over all pixel pipes and sum up the values. The 'iteration'
is done by select the pipe of interest via HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE.
There is also need to configure the mux register.
Allowing the userspace to do it all by its own feels quite error prone and not
future-proof. Thats why the kernel exports all performance domains and their
signals to the userspace via two new ioctls. So the kernel knows all performance
counters and how to sample them.
At the moment all performacne domains and signals get exported to all gpu pipe types,
but that can be changed in follow-up patches.
struct drm_etnaviv_gem_submit was extended to include so-called performance monitor
requests (pmrs). A request defines what domain and signal should be sampled (pre/post
draw cmdbuffer) and where to store the result.
The whole series can be found here:
https://github.com/austriancoder/linux/tree/perfmon-v3
The used libdrm and mesa branches to test this feature can be found here:
https://github.com/austriancoder/libdrm/commits/perfmon-v2
https://github.com/austriancoder/mesa/commits/perfmon-v2
Changes v1 -> v2:
- reworked events
- reworked uapi
- reworked enumeration of domains and signals
- process sync point with a work item to keep irq as fast as possible
- prevent GPU hang when reading pixel pipeline perf values
- all SH perf counters are accessed via perf_reg_read(..)
Changes v2 -> v3:
- reworked alloc_event(..)
- fixed pmr flag validation
Happy reviewing!
Christian Gmeiner (23):
drm/etnaviv: use bitmap to keep track of events
drm/etnaviv: make it possible to allocate multiple events
drm/etnaviv: add infrastructure to query perf counter
drm/etnaviv: add uapi for perfmon feature
drm/etnaviv: add internal representation of perfmon_request
drm/etnaviv: extend etnaviv_gpu_cmdbuf_new(..) with nr_pmrs
drm/etnaviv: add performance monitor request validation
drm/etnaviv: copy pmrs from userspace
drm/etnaviv: add performance monitor request processing
drm/etnaviv: add 'sync point' support
drm/etnaviv: clear alloced event
drm/etnaviv: use 'sync points' for performance monitor requests
drm/etnaviv: add HI perf domain
drm/etnaviv: add PE perf domain
drm/etnaviv: add SH perf domain
drm/etnaviv: add PA perf domain
drm/etnaviv: add SE perf domain
drm/etnaviv: add RA perf domain
drm/etnaviv: add TX perf domain
drm/etnaviv: add MC perf domain
drm/etnaviv: need to disable clock gating when doing profiling
drm/etnaviv: enable debug registers on demand
drm/etnaviv: submit supports performance monitor requests
drivers/gpu/drm/etnaviv/Makefile | 3 +-
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 36 +++
drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 15 +-
drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 6 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 39 ++-
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 69 ++++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 216 ++++++++++---
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 13 +-
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 447 +++++++++++++++++++++++++++
drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 48 +++
include/uapi/drm/etnaviv_drm.h | 42 ++-
12 files changed, 878 insertions(+), 57 deletions(-)
create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
--
2.13.5
More information about the dri-devel
mailing list