Quoting Tvrtko Ursulin (2019-12-19 18:00:19) > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > Expose per-client and per-engine busyness under the previously added sysfs > client root. > > The new files are one per-engine instance and located under the 'busy' > directory. Each contains a monotonically increasing nano-second resolution > times each client's jobs were executing on the GPU. > > This enables userspace to create a top-like tool for GPU utilization: > > ========================================================================== > intel-gpu-top - 935/ 935 MHz; 0% RC6; 14.73 Watts; 1097 irqs/s > > IMC reads: 1401 MiB/s > IMC writes: 4 MiB/s > > ENGINE BUSY MI_SEMA MI_WAIT > Render/3D/0 63.73% |███████████████████ | 3% 0% > Blitter/0 9.53% |██▊ | 6% 0% > Video/0 39.32% |███████████▊ | 16% 0% > Video/1 15.62% |████▋ | 0% 0% > VideoEnhance/0 0.00% | | 0% 0% > > PID NAME RCS BCS VCS VECS > 4084 gem_wsim |█████▌ ||█ || || | > 4086 gem_wsim |█▌ || ||███ || | > ========================================================================== > > v2: Use intel_context_engine_get_busy_time. > v3: New directory structure. > v4: Rebase. > v5: sysfs_attr_init. > v6: Small tidy in i915_gem_add_client. > v7: Rebase to be engine class based. > v8: > * Always enable stats. > * Walk all client contexts. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> Other than splitting it out into i915_drm_client.c (et al). It worksforme. However, it's about as useful as top, but without any means to kill/stop/reprioritise clients :( To give me actionable data, do we not need more of a perf interface where events are sent for client start/stop so that observers can record the context utilisation within their sample periods? I'm thinking of the "perf stat wsim..." use case where it gives me a breakdown of each workload. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
