From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Same old work but now rebased and series ending with some DRM docs proposing the common specification which should enable nice common userspace tools to be written.
For the moment I only have intel_gpu_top converted to use this and that seems to work okay.
v2: * Added prototype of possible amdgpu changes and spec updates to align with the common spec.
v3: * Documented that 'drm-driver' tag shall correspond with struct drm_driver.name.
v4: * Dropped amdgpu conversion from the series for now until AMD folks can find some time to finish that patch.
Test-with: 20220106164915.56855-1-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin (7): drm/i915: Explicitly track DRM clients drm/i915: Make GEM contexts track DRM clients drm/i915: Track runtime spent in closed and unreachable GEM contexts drm/i915: Track all user contexts per client drm/i915: Track context current active time drm: Document fdinfo format specification drm/i915: Expose client engine utilisation via fdinfo
Documentation/gpu/drm-usage-stats.rst | 103 +++++++++++++ Documentation/gpu/i915.rst | 27 ++++ Documentation/gpu/index.rst | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 ++++- .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + drivers/gpu/drm/i915/gt/intel_context.c | 27 +++- drivers/gpu/drm/i915/gt/intel_context.h | 15 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 24 ++- .../drm/i915/gt/intel_execlists_submission.c | 23 ++- .../gpu/drm/i915/gt/intel_gt_clock_utils.c | 4 + drivers/gpu/drm/i915/gt/intel_lrc.c | 27 ++-- drivers/gpu/drm/i915/gt/intel_lrc.h | 24 +++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 10 +- drivers/gpu/drm/i915/i915_driver.c | 9 ++ drivers/gpu/drm/i915/i915_drm_client.c | 143 ++++++++++++++++++ drivers/gpu/drm/i915/i915_drm_client.h | 66 ++++++++ drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 21 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 9 +- drivers/gpu/drm/i915/i915_gpu_error.h | 2 +- 21 files changed, 535 insertions(+), 54 deletions(-) create mode 100644 Documentation/gpu/drm-usage-stats.rst create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Tracking DRM clients more explicitly will allow later patches to accumulate past and current GPU usage in a centralised place and also consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/ consolidating between multiple file descriptors owned by the same process.
v2: Chris Wilson: * Enclose new members into dedicated structs. * Protect against failed sysfs registration.
v3: * sysfs_attr_init.
v4: * Fix for internal clients.
v5: * Use cyclic ida for client id. (Chris) * Do not leak pid reference. (Chris) * Tidy code with some locals.
v6: * Use xa_alloc_cyclic to simplify locking. (Chris) * No need to unregister individial sysfs files. (Chris) * Rebase on top of fpriv kref. * Track client closed status and reflect in sysfs.
v7: * Make drm_client more standalone concept.
v8: * Simplify sysfs show. (Chris) * Always track name and pid.
v9: * Fix cyclic id assignment.
v10: * No need for a mutex around xa_alloc_cyclic. * Refactor sysfs into own function. * Unregister sysfs before freeing pid and name. * Move clients setup into own function.
v11: * Call clients init directly from driver init. (Chris)
v12: * Do not fail client add on id wrap. (Maciej)
v13 (Lucas): Rebase.
v14: * Dropped sysfs bits.
v15: * Dropped tracking of pid/ and name. * Dropped RCU freeing of the client object.
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Reviewed-by: Chris Wilson chris@chris-wilson.co.uk # v11 Reviewed-by: Aravind Iddamsetty aravind.iddamsetty@intel.com # v11 Signed-off-by: Chris Wilson chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_driver.c | 6 +++ drivers/gpu/drm/i915/i915_drm_client.c | 68 ++++++++++++++++++++++++++ drivers/gpu/drm/i915/i915_drm_client.h | 50 +++++++++++++++++++ drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/i915_gem.c | 21 ++++++-- 6 files changed, 148 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 1b62b9f65196..65dee16c90e8 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -31,6 +31,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# core driver code i915-y += i915_driver.o \ + i915_drm_client.o \ i915_config.o \ i915_irq.o \ i915_getparam.o \ diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c index 5f2343389b5e..c9b18dadf828 100644 --- a/drivers/gpu/drm/i915/i915_driver.c +++ b/drivers/gpu/drm/i915/i915_driver.c @@ -73,6 +73,7 @@
#include "i915_debugfs.h" #include "i915_driver.h" +#include "i915_drm_client.h" #include "i915_drv.h" #include "i915_ioc32.h" #include "i915_irq.h" @@ -349,6 +350,8 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
__intel_gt_init_early(to_gt(dev_priv), dev_priv);
+ i915_drm_clients_init(&dev_priv->clients, dev_priv); + i915_gem_init_early(dev_priv);
/* This must be called before any calls to HAS_PCH_* */ @@ -368,6 +371,7 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
err_gem: i915_gem_cleanup_early(dev_priv); + i915_drm_clients_fini(&dev_priv->clients); intel_gt_driver_late_release(to_gt(dev_priv)); intel_region_ttm_device_fini(dev_priv); err_ttm: @@ -387,6 +391,7 @@ static void i915_driver_late_release(struct drm_i915_private *dev_priv) intel_irq_fini(dev_priv); intel_power_domains_cleanup(dev_priv); i915_gem_cleanup_early(dev_priv); + i915_drm_clients_fini(&dev_priv->clients); intel_gt_driver_late_release(to_gt(dev_priv)); intel_region_ttm_device_fini(dev_priv); vlv_suspend_cleanup(dev_priv); @@ -1019,6 +1024,7 @@ static void i915_driver_postclose(struct drm_device *dev, struct drm_file *file) struct drm_i915_file_private *file_priv = file->driver_priv;
i915_gem_context_close(file); + i915_drm_client_put(file_priv->client);
kfree_rcu(file_priv, rcu);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c b/drivers/gpu/drm/i915/i915_drm_client.c new file mode 100644 index 000000000000..e61e9ba15256 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_drm_client.c @@ -0,0 +1,68 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright © 2020 Intel Corporation + */ + +#include <linux/kernel.h> +#include <linux/slab.h> +#include <linux/types.h> + +#include "i915_drm_client.h" +#include "i915_gem.h" +#include "i915_utils.h" + +void i915_drm_clients_init(struct i915_drm_clients *clients, + struct drm_i915_private *i915) +{ + clients->i915 = i915; + clients->next_id = 0; + + xa_init_flags(&clients->xarray, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ); +} + +struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients) +{ + struct i915_drm_client *client; + struct xarray *xa = &clients->xarray; + int ret; + + client = kzalloc(sizeof(*client), GFP_KERNEL); + if (!client) + return ERR_PTR(-ENOMEM); + + xa_lock_irq(xa); + ret = __xa_alloc_cyclic(xa, &client->id, client, xa_limit_32b, + &clients->next_id, GFP_KERNEL); + xa_unlock_irq(xa); + if (ret < 0) + goto err; + + kref_init(&client->kref); + client->clients = clients; + + return client; + +err: + kfree(client); + + return ERR_PTR(ret); +} + +void __i915_drm_client_free(struct kref *kref) +{ + struct i915_drm_client *client = + container_of(kref, typeof(*client), kref); + struct xarray *xa = &client->clients->xarray; + unsigned long flags; + + xa_lock_irqsave(xa, flags); + __xa_erase(xa, client->id); + xa_unlock_irqrestore(xa, flags); + kfree(client); +} + +void i915_drm_clients_fini(struct i915_drm_clients *clients) +{ + GEM_BUG_ON(!xa_empty(&clients->xarray)); + xa_destroy(&clients->xarray); +} diff --git a/drivers/gpu/drm/i915/i915_drm_client.h b/drivers/gpu/drm/i915/i915_drm_client.h new file mode 100644 index 000000000000..e8986ad51176 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_drm_client.h @@ -0,0 +1,50 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2020 Intel Corporation + */ + +#ifndef __I915_DRM_CLIENT_H__ +#define __I915_DRM_CLIENT_H__ + +#include <linux/kref.h> +#include <linux/xarray.h> + +struct drm_i915_private; + +struct i915_drm_clients { + struct drm_i915_private *i915; + + struct xarray xarray; + u32 next_id; +}; + +struct i915_drm_client { + struct kref kref; + + unsigned int id; + + struct i915_drm_clients *clients; +}; + +void i915_drm_clients_init(struct i915_drm_clients *clients, + struct drm_i915_private *i915); + +static inline struct i915_drm_client * +i915_drm_client_get(struct i915_drm_client *client) +{ + kref_get(&client->kref); + return client; +} + +void __i915_drm_client_free(struct kref *kref); + +static inline void i915_drm_client_put(struct i915_drm_client *client) +{ + kref_put(&client->kref, __i915_drm_client_free); +} + +struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients); + +void i915_drm_clients_fini(struct i915_drm_clients *clients); + +#endif /* !__I915_DRM_CLIENT_H__ */ diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2f9336302e6c..7fa34888f386 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -98,6 +98,7 @@ #include "intel_wakeref.h" #include "intel_wopcm.h"
+#include "i915_drm_client.h" #include "i915_gem.h" #include "i915_gem_gtt.h" #include "i915_gpu_error.h" @@ -259,6 +260,8 @@ struct drm_i915_file_private { /** ban_score: Accumulated score of all ctx bans and fast hangs. */ atomic_t ban_score; unsigned long hang_timestamp; + + struct i915_drm_client *client; };
/* Interface history: @@ -1029,6 +1032,8 @@ struct drm_i915_private {
struct i915_pmu pmu;
+ struct i915_drm_clients clients; + struct i915_hdcp_comp_master *hdcp_master; bool hdcp_comp_added;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index e3730096abd9..296c04624383 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1201,25 +1201,40 @@ void i915_gem_cleanup_early(struct drm_i915_private *dev_priv) int i915_gem_open(struct drm_i915_private *i915, struct drm_file *file) { struct drm_i915_file_private *file_priv; - int ret; + struct i915_drm_client *client; + int ret = -ENOMEM;
DRM_DEBUG("\n");
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL); if (!file_priv) - return -ENOMEM; + goto err_alloc; + + client = i915_drm_client_add(&i915->clients); + if (IS_ERR(client)) { + ret = PTR_ERR(client); + goto err_client; + }
file->driver_priv = file_priv; file_priv->dev_priv = i915; file_priv->file = file; + file_priv->client = client;
file_priv->bsd_engine = -1; file_priv->hang_timestamp = jiffies;
ret = i915_gem_context_open(i915, file); if (ret) - kfree(file_priv); + goto err_context; + + return 0;
+err_context: + i915_drm_client_put(client); +err_client: + kfree(file_priv); +err_alloc: return ret; }
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Make GEM contexts keep a reference to i915_drm_client for the whole of of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris) v3 (Lucas): Finish constructing ctx before adding it to the list v4 (Ram): Rebase. v5: Trivial rebase for proto ctx changes. v6: Rebase after clients no longer track name and pid.
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Reviewed-by: Chris Wilson chris@chris-wilson.co.uk # v5 Reviewed-by: Aravind Iddamsetty aravind.iddamsetty@intel.com # v5 Signed-off-by: Chris Wilson chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++++ drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++ 2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index ebbac2ea0833..b093d3e3a78c 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -1230,6 +1230,9 @@ static void i915_gem_context_release_work(struct work_struct *work) if (ctx->pxp_wakeref) intel_runtime_pm_put(&ctx->i915->runtime_pm, ctx->pxp_wakeref);
+ if (ctx->client) + i915_drm_client_put(ctx->client); + mutex_destroy(&ctx->engines_mutex); mutex_destroy(&ctx->lut_mutex);
@@ -1653,6 +1656,8 @@ static void gem_context_register(struct i915_gem_context *ctx, ctx->file_priv = fpriv;
ctx->pid = get_task_pid(current, PIDTYPE_PID); + ctx->client = i915_drm_client_get(fpriv->client); + snprintf(ctx->name, sizeof(ctx->name), "%s[%d]", current->comm, pid_nr(ctx->pid));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h index 282cdb8a5c5a..93d24f189ba9 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h @@ -293,6 +293,9 @@ struct i915_gem_context { /** @link: place with &drm_i915_private.context_list */ struct list_head link;
+ /** @client: struct i915_drm_client */ + struct i915_drm_client *client; + /** * @ref: reference count *
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
As contexts are abandoned we want to remember how much GPU time they used (per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how much GPU time they used (per class) so later we can used it for smarter purposes.
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Reviewed-by: Aravind Iddamsetty aravind.iddamsetty@intel.com Reviewed-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Chris Wilson chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 +++++++++++++++++++-- drivers/gpu/drm/i915/i915_drm_client.h | 7 ++++++ 2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index b093d3e3a78c..064f4688b9ec 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -1004,23 +1004,44 @@ static void free_engines_rcu(struct rcu_head *rcu) free_engines(engines); }
+static void accumulate_runtime(struct i915_drm_client *client, + struct i915_gem_engines *engines) +{ + struct i915_gem_engines_iter it; + struct intel_context *ce; + + if (!client) + return; + + /* Transfer accumulated runtime to the parent GEM context. */ + for_each_gem_engine(ce, engines, it) { + unsigned int class = ce->engine->uabi_class; + + GEM_BUG_ON(class >= ARRAY_SIZE(client->past_runtime)); + atomic64_add(intel_context_get_total_runtime_ns(ce), + &client->past_runtime[class]); + } +} + static int engines_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state) { struct i915_gem_engines *engines = container_of(fence, typeof(*engines), fence); + struct i915_gem_context *ctx = engines->ctx;
switch (state) { case FENCE_COMPLETE: if (!list_empty(&engines->link)) { - struct i915_gem_context *ctx = engines->ctx; unsigned long flags;
spin_lock_irqsave(&ctx->stale.lock, flags); list_del(&engines->link); spin_unlock_irqrestore(&ctx->stale.lock, flags); } - i915_gem_context_put(engines->ctx); + accumulate_runtime(ctx->client, engines); + i915_gem_context_put(ctx); + break;
case FENCE_FREE: diff --git a/drivers/gpu/drm/i915/i915_drm_client.h b/drivers/gpu/drm/i915/i915_drm_client.h index e8986ad51176..9d80d9f715ee 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.h +++ b/drivers/gpu/drm/i915/i915_drm_client.h @@ -9,6 +9,8 @@ #include <linux/kref.h> #include <linux/xarray.h>
+#include "gt/intel_engine_types.h" + struct drm_i915_private;
struct i915_drm_clients { @@ -24,6 +26,11 @@ struct i915_drm_client { unsigned int id;
struct i915_drm_clients *clients; + + /** + * @past_runtime: Accumulation of pphwsp runtimes from closed contexts. + */ + atomic64_t past_runtime[MAX_ENGINE_CLASS + 1]; };
void i915_drm_clients_init(struct i915_drm_clients *clients,
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
We soon want to start answering questions like how much GPU time is the context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a separate list.
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Reviewed-by: Aravind Iddamsetty aravind.iddamsetty@intel.com Reviewed-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Chris Wilson chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 ++++++++++++ drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++ drivers/gpu/drm/i915/i915_drm_client.c | 2 ++ drivers/gpu/drm/i915/i915_drm_client.h | 5 +++++ 4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index 064f4688b9ec..84925ae970a3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -1464,6 +1464,7 @@ static void set_closed_name(struct i915_gem_context *ctx)
static void context_close(struct i915_gem_context *ctx) { + struct i915_drm_client *client; struct i915_address_space *vm;
/* Flush any concurrent set_engines() */ @@ -1501,6 +1502,13 @@ static void context_close(struct i915_gem_context *ctx) list_del(&ctx->link); spin_unlock(&ctx->i915->gem.contexts.lock);
+ client = ctx->client; + if (client) { + spin_lock(&client->ctx_lock); + list_del_rcu(&ctx->client_link); + spin_unlock(&client->ctx_lock); + } + mutex_unlock(&ctx->mutex);
/* @@ -1686,6 +1694,10 @@ static void gem_context_register(struct i915_gem_context *ctx, old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL); WARN_ON(old);
+ spin_lock(&ctx->client->ctx_lock); + list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list); + spin_unlock(&ctx->client->ctx_lock); + spin_lock(&i915->gem.contexts.lock); list_add_tail(&ctx->link, &i915->gem.contexts.list); spin_unlock(&i915->gem.contexts.lock); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h index 93d24f189ba9..5946dcb11cf5 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h @@ -296,6 +296,9 @@ struct i915_gem_context { /** @client: struct i915_drm_client */ struct i915_drm_client *client;
+ /** link: &drm_client.context_list */ + struct list_head client_link; + /** * @ref: reference count * diff --git a/drivers/gpu/drm/i915/i915_drm_client.c b/drivers/gpu/drm/i915/i915_drm_client.c index e61e9ba15256..91a8559bebf7 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.c +++ b/drivers/gpu/drm/i915/i915_drm_client.c @@ -38,6 +38,8 @@ struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients) goto err;
kref_init(&client->kref); + spin_lock_init(&client->ctx_lock); + INIT_LIST_HEAD(&client->ctx_list); client->clients = clients;
return client; diff --git a/drivers/gpu/drm/i915/i915_drm_client.h b/drivers/gpu/drm/i915/i915_drm_client.h index 9d80d9f715ee..7416e18aa33c 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.h +++ b/drivers/gpu/drm/i915/i915_drm_client.h @@ -7,6 +7,8 @@ #define __I915_DRM_CLIENT_H__
#include <linux/kref.h> +#include <linux/list.h> +#include <linux/spinlock.h> #include <linux/xarray.h>
#include "gt/intel_engine_types.h" @@ -25,6 +27,9 @@ struct i915_drm_client {
unsigned int id;
+ spinlock_t ctx_lock; /* For add/remove from ctx_list. */ + struct list_head ctx_list; /* List of contexts belonging to client. */ + struct i915_drm_clients *clients;
/**
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Track context active (on hardware) status together with the start timestamp.
This will be used to provide better granularity of context runtime reporting in conjunction with already tracked pphwsp accumulated runtime.
The latter is only updated on context save so does not give us visibility to any currently executing work.
As part of the patch the existing runtime tracking data is moved under the new ce->stats member and updated under the seqlock. This provides the ability to atomically read out accumulated plus active runtime.
v2: * Rename and make __intel_context_get_active_time unlocked.
v3: * Use GRAPHICS_VER.
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Reviewed-by: Aravind Iddamsetty aravind.iddamsetty@intel.com # v1 Reviewed-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Chris Wilson chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/gt/intel_context.c | 27 ++++++++++++++++++- drivers/gpu/drm/i915/gt/intel_context.h | 15 ++++------- drivers/gpu/drm/i915/gt/intel_context_types.h | 24 +++++++++++------ .../drm/i915/gt/intel_execlists_submission.c | 23 ++++++++++++---- .../gpu/drm/i915/gt/intel_gt_clock_utils.c | 4 +++ drivers/gpu/drm/i915/gt/intel_lrc.c | 27 ++++++++++--------- drivers/gpu/drm/i915/gt/intel_lrc.h | 24 +++++++++++++++++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 10 +++---- drivers/gpu/drm/i915/i915_gpu_error.c | 9 +++---- drivers/gpu/drm/i915/i915_gpu_error.h | 2 +- 10 files changed, 116 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 5d0ec7c49b6a..ebbf3ad5ee8d 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -386,7 +386,7 @@ intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine) ce->ring = NULL; ce->ring_size = SZ_4K;
- ewma_runtime_init(&ce->runtime.avg); + ewma_runtime_init(&ce->stats.runtime.avg);
ce->vm = i915_vm_get(engine->gt->vm);
@@ -576,6 +576,31 @@ void intel_context_bind_parent_child(struct intel_context *parent, child->parallel.parent = parent; }
+u64 intel_context_get_total_runtime_ns(const struct intel_context *ce) +{ + u64 total, active; + + total = ce->stats.runtime.total; + if (ce->ops->flags & COPS_RUNTIME_CYCLES) + total *= ce->engine->gt->clock_period_ns; + + active = READ_ONCE(ce->stats.active); + if (active) + active = intel_context_clock() - active; + + return total + active; +} + +u64 intel_context_get_avg_runtime_ns(struct intel_context *ce) +{ + u64 avg = ewma_runtime_read(&ce->stats.runtime.avg); + + if (ce->ops->flags & COPS_RUNTIME_CYCLES) + avg *= ce->engine->gt->clock_period_ns; + + return avg; +} + #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) #include "selftest_context.c" #endif diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h index d8c74bbf9aae..b7d3214d2cdd 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.h +++ b/drivers/gpu/drm/i915/gt/intel_context.h @@ -351,18 +351,13 @@ intel_context_clear_nopreempt(struct intel_context *ce) clear_bit(CONTEXT_NOPREEMPT, &ce->flags); }
-static inline u64 intel_context_get_total_runtime_ns(struct intel_context *ce) -{ - const u32 period = ce->engine->gt->clock_period_ns; - - return READ_ONCE(ce->runtime.total) * period; -} +u64 intel_context_get_total_runtime_ns(const struct intel_context *ce); +u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
-static inline u64 intel_context_get_avg_runtime_ns(struct intel_context *ce) +static inline u64 intel_context_clock(void) { - const u32 period = ce->engine->gt->clock_period_ns; - - return mul_u32_u32(ewma_runtime_read(&ce->runtime.avg), period); + /* As we mix CS cycles with CPU clocks, use the raw monotonic clock. */ + return ktime_get_raw_fast_ns(); }
#endif /* __INTEL_CONTEXT_H__ */ diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h index 30cd81ad8911..09f82545789f 100644 --- a/drivers/gpu/drm/i915/gt/intel_context_types.h +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h @@ -35,6 +35,9 @@ struct intel_context_ops { #define COPS_HAS_INFLIGHT_BIT 0 #define COPS_HAS_INFLIGHT BIT(COPS_HAS_INFLIGHT_BIT)
+#define COPS_RUNTIME_CYCLES_BIT 1 +#define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT) + int (*alloc)(struct intel_context *ce);
void (*ban)(struct intel_context *ce, struct i915_request *rq); @@ -134,14 +137,19 @@ struct intel_context { } lrc; u32 tag; /* cookie passed to HW to track this context on submission */
- /* Time on GPU as tracked by the hw. */ - struct { - struct ewma_runtime avg; - u64 total; - u32 last; - I915_SELFTEST_DECLARE(u32 num_underflow); - I915_SELFTEST_DECLARE(u32 max_underflow); - } runtime; + /** stats: Context GPU engine busyness tracking. */ + struct intel_context_stats { + u64 active; + + /* Time on GPU as tracked by the hw. */ + struct { + struct ewma_runtime avg; + u64 total; + u32 last; + I915_SELFTEST_DECLARE(u32 num_underflow); + I915_SELFTEST_DECLARE(u32 max_underflow); + } runtime; + } stats;
unsigned int active_count; /* protected by timeline->mutex */
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index be56d0b41892..78ee5e048435 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -622,8 +622,6 @@ static void __execlists_schedule_out(struct i915_request * const rq, GEM_BUG_ON(test_bit(ccid - 1, &engine->context_tag)); __set_bit(ccid - 1, &engine->context_tag); } - - lrc_update_runtime(ce); intel_engine_context_out(engine); execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT); if (engine->fw_domain && !--engine->fw_active) @@ -2004,8 +2002,23 @@ process_csb(struct intel_engine_cs *engine, struct i915_request **inactive) * and merits a fresh timeslice. We reinstall the timer after * inspecting the queue to see if we need to resumbit. */ - if (*prev != *execlists->active) /* elide lite-restores */ + if (*prev != *execlists->active) { /* elide lite-restores */ + /* + * Note the inherent discrepancy between the HW runtime, + * recorded as part of the context switch, and the CPU + * adjustment for active contexts. We have to hope that + * the delay in processing the CS event is very small + * and consistent. It works to our advantage to have + * the CPU adjustment _undershoot_ (i.e. start later than) + * the CS timestamp so we never overreport the runtime + * and correct overselves later when updating from HW. + */ + if (*prev) + lrc_runtime_stop((*prev)->context); + if (*execlists->active) + lrc_runtime_start((*execlists->active)->context); new_timeslice(execlists); + }
return inactive; } @@ -2637,7 +2650,7 @@ execlists_create_parallel(struct intel_engine_cs **engines, }
static const struct intel_context_ops execlists_context_ops = { - .flags = COPS_HAS_INFLIGHT, + .flags = COPS_HAS_INFLIGHT | COPS_RUNTIME_CYCLES,
.alloc = execlists_context_alloc,
@@ -3692,7 +3705,7 @@ virtual_get_sibling(struct intel_engine_cs *engine, unsigned int sibling) }
static const struct intel_context_ops virtual_context_ops = { - .flags = COPS_HAS_INFLIGHT, + .flags = COPS_HAS_INFLIGHT | COPS_RUNTIME_CYCLES,
.alloc = virtual_context_alloc,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c b/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c index 3513d6f90747..c5b561f71756 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c @@ -159,6 +159,10 @@ void intel_gt_init_clock_frequency(struct intel_gt *gt) if (gt->clock_frequency) gt->clock_period_ns = intel_gt_clock_interval_to_ns(gt, 1);
+ /* Icelake appears to use another fixed frequency for CTX_TIMESTAMP */ + if (GRAPHICS_VER(gt->i915) == 11) + gt->clock_period_ns = NSEC_PER_SEC / 13750000; + GT_TRACE(gt, "Using clock frequency: %dkHz, period: %dns, wrap: %lldms\n", gt->clock_frequency / 1000, diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 84456ffeb4cd..536d43feee00 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -774,7 +774,7 @@ static void init_common_regs(u32 * const regs, CTX_CTRL_RS_CTX_ENABLE); regs[CTX_CONTEXT_CONTROL] = ctl;
- regs[CTX_TIMESTAMP] = ce->runtime.last; + regs[CTX_TIMESTAMP] = ce->stats.runtime.last; }
static void init_wa_bb_regs(u32 * const regs, @@ -1682,35 +1682,36 @@ void lrc_init_wa_ctx(struct intel_engine_cs *engine) } }
-static void st_update_runtime_underflow(struct intel_context *ce, s32 dt) +static void st_runtime_underflow(struct intel_context_stats *stats, s32 dt) { #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) - ce->runtime.num_underflow++; - ce->runtime.max_underflow = max_t(u32, ce->runtime.max_underflow, -dt); + stats->runtime.num_underflow++; + stats->runtime.max_underflow = + max_t(u32, stats->runtime.max_underflow, -dt); #endif }
void lrc_update_runtime(struct intel_context *ce) { + struct intel_context_stats *stats = &ce->stats; u32 old; s32 dt;
- if (intel_context_is_barrier(ce)) + old = stats->runtime.last; + stats->runtime.last = lrc_get_runtime(ce); + dt = stats->runtime.last - old; + if (!dt) return;
- old = ce->runtime.last; - ce->runtime.last = lrc_get_runtime(ce); - dt = ce->runtime.last - old; - if (unlikely(dt < 0)) { CE_TRACE(ce, "runtime underflow: last=%u, new=%u, delta=%d\n", - old, ce->runtime.last, dt); - st_update_runtime_underflow(ce, dt); + old, stats->runtime.last, dt); + st_runtime_underflow(stats, dt); return; }
- ewma_runtime_add(&ce->runtime.avg, dt); - ce->runtime.total += dt; + ewma_runtime_add(&stats->runtime.avg, dt); + stats->runtime.total += dt; }
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h b/drivers/gpu/drm/i915/gt/intel_lrc.h index 7f697845c4cf..8073674538d7 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.h +++ b/drivers/gpu/drm/i915/gt/intel_lrc.h @@ -79,4 +79,28 @@ static inline u32 lrc_get_runtime(const struct intel_context *ce) return READ_ONCE(ce->lrc_reg_state[CTX_TIMESTAMP]); }
+static inline void lrc_runtime_start(struct intel_context *ce) +{ + struct intel_context_stats *stats = &ce->stats; + + if (intel_context_is_barrier(ce)) + return; + + if (stats->active) + return; + + WRITE_ONCE(stats->active, intel_context_clock()); +} + +static inline void lrc_runtime_stop(struct intel_context *ce) +{ + struct intel_context_stats *stats = &ce->stats; + + if (!stats->active) + return; + + lrc_update_runtime(ce); + WRITE_ONCE(stats->active, 0); +} + #endif /* __INTEL_LRC_H__ */ diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c b/drivers/gpu/drm/i915/gt/selftest_lrc.c index 618c905daa19..1cc2e8485bf0 100644 --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c @@ -1751,8 +1751,8 @@ static int __live_pphwsp_runtime(struct intel_engine_cs *engine) if (IS_ERR(ce)) return PTR_ERR(ce);
- ce->runtime.num_underflow = 0; - ce->runtime.max_underflow = 0; + ce->stats.runtime.num_underflow = 0; + ce->stats.runtime.max_underflow = 0;
do { unsigned int loop = 1024; @@ -1790,11 +1790,11 @@ static int __live_pphwsp_runtime(struct intel_engine_cs *engine) intel_context_get_avg_runtime_ns(ce));
err = 0; - if (ce->runtime.num_underflow) { + if (ce->stats.runtime.num_underflow) { pr_err("%s: pphwsp underflow %u time(s), max %u cycles!\n", engine->name, - ce->runtime.num_underflow, - ce->runtime.max_underflow); + ce->stats.runtime.num_underflow, + ce->stats.runtime.max_underflow); GEM_TRACE_DUMP(); err = -EOVERFLOW; } diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 5ae812d60abe..9c3b81b2d602 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -505,13 +505,10 @@ static void error_print_context(struct drm_i915_error_state_buf *m, const char *header, const struct i915_gem_context_coredump *ctx) { - const u32 period = to_gt(m->i915)->clock_period_ns; - err_printf(m, "%s%s[%d] prio %d, guilty %d active %d, runtime total %lluns, avg %lluns\n", header, ctx->comm, ctx->pid, ctx->sched_attr.priority, ctx->guilty, ctx->active, - ctx->total_runtime * period, - mul_u32_u32(ctx->avg_runtime, period)); + ctx->total_runtime, ctx->avg_runtime); }
static struct i915_vma_coredump * @@ -1313,8 +1310,8 @@ static bool record_context(struct i915_gem_context_coredump *e, e->guilty = atomic_read(&ctx->guilty_count); e->active = atomic_read(&ctx->active_count);
- e->total_runtime = rq->context->runtime.total; - e->avg_runtime = ewma_runtime_read(&rq->context->runtime.avg); + e->total_runtime = intel_context_get_total_runtime_ns(rq->context); + e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
simulated = i915_gem_context_no_error_capture(ctx);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h b/drivers/gpu/drm/i915/i915_gpu_error.h index 5aedf5129814..e62637cae3c2 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.h +++ b/drivers/gpu/drm/i915/i915_gpu_error.h @@ -88,7 +88,7 @@ struct intel_engine_coredump { char comm[TASK_COMM_LEN];
u64 total_runtime; - u32 avg_runtime; + u64 avg_runtime;
pid_t pid; int active;
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Proposal to standardise the fdinfo text format as optionally output by DRM drivers.
Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM.
i915 implements a subset of the spec, everything apart from the memory stats currently, and a matching intel_gpu_top tool exists.
Open is to see if AMD can migrate to using the proposed GPU utilisation key-value pairs, or if they are not workable to see whether to go vendor specific, or if a standardised alternative can be found which is workable for both drivers.
Same for the memory utilisation key-value pairs proposal.
v2: * Update for removal of name and pid.
v3: * 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel)
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Cc: David M Nieto David.Nieto@amd.com Cc: Christian König christian.koenig@amd.com Cc: Daniel Vetter daniel@ffwll.ch Cc: Daniel Stone daniel@fooishbar.org Cc: Chris Healy cphealy@gmail.com Acked-by: Christian König christian.koenig@amd.com --- Documentation/gpu/drm-usage-stats.rst | 97 +++++++++++++++++++++++++++ Documentation/gpu/index.rst | 1 + 2 files changed, 98 insertions(+) create mode 100644 Documentation/gpu/drm-usage-stats.rst
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst new file mode 100644 index 000000000000..c669026be244 --- /dev/null +++ b/Documentation/gpu/drm-usage-stats.rst @@ -0,0 +1,97 @@ +.. _drm-client-usage-stats: + +====================== +DRM client usage stats +====================== + +DRM drivers can choose to export partly standardised text output via the +`fops->show_fdinfo()` as part of the driver specific file operations registered +in the `struct drm_driver` object registered with the DRM core. + +One purpose of this output is to enable writing as generic as practicaly +feasible `top(1)` like userspace monitoring tools. + +Given the differences between various DRM drivers the specification of the +output is split between common and driver specific parts. Having said that, +wherever possible effort should still be made to standardise as much as +possible. + +File format specification +========================= + +- File shall contain one key value pair per one line of text. +- Colon character (`:`) must be used to delimit keys and values. +- All keys shall be prefixed with `drm-`. +- Whitespace between the delimiter and first non-whitespace character shall be + ignored when parsing. +- Neither keys or values are allowed to contain whitespace characters. +- Numerical key value pairs can end with optional unit string. +- Data type of the value is fixed as defined in the specification. + +Key types +--------- + +1. Mandatory, fully standardised. +2. Optional, fully standardised. +3. Driver specific. + +Data types +---------- + +- <uint> - Unsigned integer without defining the maximum value. +- <str> - String excluding any above defined reserved characters or whitespace. + +Mandatory fully standardised keys +--------------------------------- + +- drm-driver: <str> + +String shall contain the name this driver registered as via the respective +`struct drm_driver` data structure. + +Optional fully standardised keys +-------------------------------- + +- drm-pdev: aaaa:bb.cc.d + +For PCI devices this should contain the PCI slot address of the device in +question. + +- drm-client-id: <uint> + +Unique value relating to the open DRM file descriptor used to distinguish +duplicated and shared file descriptors. Conceptually the value should map 1:1 +to the in kernel representation of `struct drm_file` instances. + +Uniqueness of the value shall be either globally unique, or unique within the +scope of each device, in which case `drm-pdev` shall be present as well. + +Userspace should make sure to not double account any usage statistics by using +the above described criteria in order to associate data to individual clients. + +- drm-engine-<str>: <uint> ns + +GPUs usually contain multiple execution engines. Each shall be given a stable +and unique name (str), with possible values documented in the driver specific +documentation. + +Value shall be in specified time units which the respective GPU engine spent +busy executing workloads belonging to this client. + +Values are not required to be constantly monotonic if it makes the driver +implementation easier, but are required to catch up with the previously reported +larger value within a reasonable period. Upon observing a value lower than what +was previously read, userspace is expected to stay with that larger previous +value until a monotonic update is seen. + +- drm-memory-<str>: <uint> [KiB|MiB] + +Each possible memory type which can be used to store buffer objects by the +GPU in question shall be given a stable and unique name to be returned as the +string here. + +Value shall reflect the amount of storage currently consumed by the buffer +object belong to this client, in the respective memory region. + +Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' +indicating kibi- or mebi-bytes. diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index b9c1214d8f23..b99dede9a5b1 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi + drm-usage-stats driver-uapi drm-client drivers
On Thu, Jan 06, 2022 at 04:55:35PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Proposal to standardise the fdinfo text format as optionally output by DRM drivers.
Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM.
i915 implements a subset of the spec, everything apart from the memory stats currently, and a matching intel_gpu_top tool exists.
Open is to see if AMD can migrate to using the proposed GPU utilisation key-value pairs, or if they are not workable to see whether to go vendor specific, or if a standardised alternative can be found which is workable for both drivers.
Same for the memory utilisation key-value pairs proposal.
v2:
- Update for removal of name and pid.
v3:
- 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel)
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Cc: David M Nieto David.Nieto@amd.com Cc: Christian König christian.koenig@amd.com Cc: Daniel Vetter daniel@ffwll.ch Cc: Daniel Stone daniel@fooishbar.org Cc: Chris Healy cphealy@gmail.com Acked-by: Christian König christian.koenig@amd.com
I'm assuming this ack here and later on is a "amdgpu plans to use this too" kind of affair. Especially also in the lights of eventually using matching semantics for cgroups and everything else tied to gpu execution resource management.
If not I'm mildly worried that we're creating fake-standard stuff here which cannot actually be used by anything resembling driver-agnostic userspace. -Daniel
Documentation/gpu/drm-usage-stats.rst | 97 +++++++++++++++++++++++++++ Documentation/gpu/index.rst | 1 + 2 files changed, 98 insertions(+) create mode 100644 Documentation/gpu/drm-usage-stats.rst
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst new file mode 100644 index 000000000000..c669026be244 --- /dev/null +++ b/Documentation/gpu/drm-usage-stats.rst @@ -0,0 +1,97 @@ +.. _drm-client-usage-stats:
+====================== +DRM client usage stats +======================
+DRM drivers can choose to export partly standardised text output via the +`fops->show_fdinfo()` as part of the driver specific file operations registered +in the `struct drm_driver` object registered with the DRM core.
+One purpose of this output is to enable writing as generic as practicaly +feasible `top(1)` like userspace monitoring tools.
+Given the differences between various DRM drivers the specification of the +output is split between common and driver specific parts. Having said that, +wherever possible effort should still be made to standardise as much as +possible.
+File format specification +=========================
+- File shall contain one key value pair per one line of text. +- Colon character (`:`) must be used to delimit keys and values. +- All keys shall be prefixed with `drm-`. +- Whitespace between the delimiter and first non-whitespace character shall be
- ignored when parsing.
+- Neither keys or values are allowed to contain whitespace characters. +- Numerical key value pairs can end with optional unit string. +- Data type of the value is fixed as defined in the specification.
+Key types +---------
+1. Mandatory, fully standardised. +2. Optional, fully standardised. +3. Driver specific.
+Data types +----------
+- <uint> - Unsigned integer without defining the maximum value. +- <str> - String excluding any above defined reserved characters or whitespace.
+Mandatory fully standardised keys +---------------------------------
+- drm-driver: <str>
+String shall contain the name this driver registered as via the respective +`struct drm_driver` data structure.
+Optional fully standardised keys +--------------------------------
+- drm-pdev: aaaa:bb.cc.d
+For PCI devices this should contain the PCI slot address of the device in +question.
+- drm-client-id: <uint>
+Unique value relating to the open DRM file descriptor used to distinguish +duplicated and shared file descriptors. Conceptually the value should map 1:1 +to the in kernel representation of `struct drm_file` instances.
+Uniqueness of the value shall be either globally unique, or unique within the +scope of each device, in which case `drm-pdev` shall be present as well.
+Userspace should make sure to not double account any usage statistics by using +the above described criteria in order to associate data to individual clients.
+- drm-engine-<str>: <uint> ns
+GPUs usually contain multiple execution engines. Each shall be given a stable +and unique name (str), with possible values documented in the driver specific +documentation.
+Value shall be in specified time units which the respective GPU engine spent +busy executing workloads belonging to this client.
+Values are not required to be constantly monotonic if it makes the driver +implementation easier, but are required to catch up with the previously reported +larger value within a reasonable period. Upon observing a value lower than what +was previously read, userspace is expected to stay with that larger previous +value until a monotonic update is seen.
+- drm-memory-<str>: <uint> [KiB|MiB]
+Each possible memory type which can be used to store buffer objects by the +GPU in question shall be given a stable and unique name to be returned as the +string here.
+Value shall reflect the amount of storage currently consumed by the buffer +object belong to this client, in the respective memory region.
+Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' +indicating kibi- or mebi-bytes. diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index b9c1214d8f23..b99dede9a5b1 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi
- drm-usage-stats driver-uapi drm-client drivers
-- 2.32.0
On 19/01/2022 15:08, Daniel Vetter wrote:
On Thu, Jan 06, 2022 at 04:55:35PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Proposal to standardise the fdinfo text format as optionally output by DRM drivers.
Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM.
i915 implements a subset of the spec, everything apart from the memory stats currently, and a matching intel_gpu_top tool exists.
Open is to see if AMD can migrate to using the proposed GPU utilisation key-value pairs, or if they are not workable to see whether to go vendor specific, or if a standardised alternative can be found which is workable for both drivers.
Same for the memory utilisation key-value pairs proposal.
v2:
- Update for removal of name and pid.
v3:
- 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel)
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Cc: David M Nieto David.Nieto@amd.com Cc: Christian König christian.koenig@amd.com Cc: Daniel Vetter daniel@ffwll.ch Cc: Daniel Stone daniel@fooishbar.org Cc: Chris Healy cphealy@gmail.com Acked-by: Christian König christian.koenig@amd.com
I'm assuming this ack here and later on is a "amdgpu plans to use this too" kind of affair. Especially also in the lights of eventually using matching semantics for cgroups and everything else tied to gpu execution resource management.
If not I'm mildly worried that we're creating fake-standard stuff here which cannot actually be used by anything resembling driver-agnostic userspace.
Hard to say how much adoption there would be.
At least on the statement of that the proposed spec cannot be used for driver agnostic userspace, do you have concrete concerns with the spec I proposed, or are just going by the lack of continuous engagement by any third party?
Apart from AMD, during past postings Daniel Stone also had positive feedback (along the lines of "works the driver I am familiar with"). I don't know if I have missed someone else who provided feedback, hope not.
There is of course the option of dropping the idea of trying to document a common spec, or to do anything cross-driver at this point. AFAIR it was your push to try this, and I agreed it would be a good thing if it worked out. But given AMD already exposes stuff in fdinfo, I don't think it would be a blocker for merging the i915 side even if we decided to drop the standardisation effort for now. Given I am maintaining this i915 code from ~2018 and there is a lot of interest from users it would be good to put it in.
Regards,
Tvrtko
On Wed, Jan 19, 2022 at 7:09 AM Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Jan 06, 2022 at 04:55:35PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Proposal to standardise the fdinfo text format as optionally output by DRM drivers.
Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM.
i915 implements a subset of the spec, everything apart from the memory stats currently, and a matching intel_gpu_top tool exists.
Open is to see if AMD can migrate to using the proposed GPU utilisation key-value pairs, or if they are not workable to see whether to go vendor specific, or if a standardised alternative can be found which is workable for both drivers.
Same for the memory utilisation key-value pairs proposal.
v2:
- Update for removal of name and pid.
v3:
- 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel)
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Cc: David M Nieto David.Nieto@amd.com Cc: Christian König christian.koenig@amd.com Cc: Daniel Vetter daniel@ffwll.ch Cc: Daniel Stone daniel@fooishbar.org Cc: Chris Healy cphealy@gmail.com Acked-by: Christian König christian.koenig@amd.com
I'm assuming this ack here and later on is a "amdgpu plans to use this too" kind of affair. Especially also in the lights of eventually using matching semantics for cgroups and everything else tied to gpu execution resource management.
If not I'm mildly worried that we're creating fake-standard stuff here which cannot actually be used by anything resembling driver-agnostic userspace.
I think I could implement something like this for drm/msm. I am a bit uncertain about the memory stats (ie. how are we intended to account for imported/exported/shared bo's)? But we already track cycles+time per submit for devfreq, it would be pretty easy to add per drm_file counters to accumulate the per-submit results. We could even track per-context (submitqueue) for processes that have more than a single context, although not sure if that is useful.
And I think there is probably some room for shared helper to print parts other than the per-engine stats (and maybe memory stats, although even that could be a shared implementation for some drivers).. with a driver callback for the non-generic parts, ie. something like:
drm_driver::show_client_stats(struct drm_file *, struct drm_printer *)
but that can come later.
If there is a tool somewhere that displays this info, that would be useful for testing my implementation.
BR, -R
-Daniel
Documentation/gpu/drm-usage-stats.rst | 97 +++++++++++++++++++++++++++ Documentation/gpu/index.rst | 1 + 2 files changed, 98 insertions(+) create mode 100644 Documentation/gpu/drm-usage-stats.rst
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst new file mode 100644 index 000000000000..c669026be244 --- /dev/null +++ b/Documentation/gpu/drm-usage-stats.rst @@ -0,0 +1,97 @@ +.. _drm-client-usage-stats:
+====================== +DRM client usage stats +======================
+DRM drivers can choose to export partly standardised text output via the +`fops->show_fdinfo()` as part of the driver specific file operations registered +in the `struct drm_driver` object registered with the DRM core.
+One purpose of this output is to enable writing as generic as practicaly +feasible `top(1)` like userspace monitoring tools.
+Given the differences between various DRM drivers the specification of the +output is split between common and driver specific parts. Having said that, +wherever possible effort should still be made to standardise as much as +possible.
+File format specification +=========================
+- File shall contain one key value pair per one line of text. +- Colon character (`:`) must be used to delimit keys and values. +- All keys shall be prefixed with `drm-`. +- Whitespace between the delimiter and first non-whitespace character shall be
- ignored when parsing.
+- Neither keys or values are allowed to contain whitespace characters. +- Numerical key value pairs can end with optional unit string. +- Data type of the value is fixed as defined in the specification.
+Key types +---------
+1. Mandatory, fully standardised. +2. Optional, fully standardised. +3. Driver specific.
+Data types +----------
+- <uint> - Unsigned integer without defining the maximum value. +- <str> - String excluding any above defined reserved characters or whitespace.
+Mandatory fully standardised keys +---------------------------------
+- drm-driver: <str>
+String shall contain the name this driver registered as via the respective +`struct drm_driver` data structure.
+Optional fully standardised keys +--------------------------------
+- drm-pdev: aaaa:bb.cc.d
+For PCI devices this should contain the PCI slot address of the device in +question.
+- drm-client-id: <uint>
+Unique value relating to the open DRM file descriptor used to distinguish +duplicated and shared file descriptors. Conceptually the value should map 1:1 +to the in kernel representation of `struct drm_file` instances.
+Uniqueness of the value shall be either globally unique, or unique within the +scope of each device, in which case `drm-pdev` shall be present as well.
+Userspace should make sure to not double account any usage statistics by using +the above described criteria in order to associate data to individual clients.
+- drm-engine-<str>: <uint> ns
+GPUs usually contain multiple execution engines. Each shall be given a stable +and unique name (str), with possible values documented in the driver specific +documentation.
+Value shall be in specified time units which the respective GPU engine spent +busy executing workloads belonging to this client.
+Values are not required to be constantly monotonic if it makes the driver +implementation easier, but are required to catch up with the previously reported +larger value within a reasonable period. Upon observing a value lower than what +was previously read, userspace is expected to stay with that larger previous +value until a monotonic update is seen.
+- drm-memory-<str>: <uint> [KiB|MiB]
+Each possible memory type which can be used to store buffer objects by the +GPU in question shall be given a stable and unique name to be returned as the +string here.
+Value shall reflect the amount of storage currently consumed by the buffer +object belong to this client, in the respective memory region.
+Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' +indicating kibi- or mebi-bytes. diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index b9c1214d8f23..b99dede9a5b1 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi
- drm-usage-stats driver-uapi drm-client drivers
-- 2.32.0
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On 20/01/2022 16:44, Rob Clark wrote:
On Wed, Jan 19, 2022 at 7:09 AM Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Jan 06, 2022 at 04:55:35PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Proposal to standardise the fdinfo text format as optionally output by DRM drivers.
Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM.
i915 implements a subset of the spec, everything apart from the memory stats currently, and a matching intel_gpu_top tool exists.
Open is to see if AMD can migrate to using the proposed GPU utilisation key-value pairs, or if they are not workable to see whether to go vendor specific, or if a standardised alternative can be found which is workable for both drivers.
Same for the memory utilisation key-value pairs proposal.
v2:
- Update for removal of name and pid.
v3:
- 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel)
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Cc: David M Nieto David.Nieto@amd.com Cc: Christian König christian.koenig@amd.com Cc: Daniel Vetter daniel@ffwll.ch Cc: Daniel Stone daniel@fooishbar.org Cc: Chris Healy cphealy@gmail.com Acked-by: Christian König christian.koenig@amd.com
I'm assuming this ack here and later on is a "amdgpu plans to use this too" kind of affair. Especially also in the lights of eventually using matching semantics for cgroups and everything else tied to gpu execution resource management.
If not I'm mildly worried that we're creating fake-standard stuff here which cannot actually be used by anything resembling driver-agnostic userspace.
I think I could implement something like this for drm/msm. I am a bit uncertain about the memory stats (ie. how are we intended to account for imported/exported/shared bo's)? But we already track cycles+time per submit for devfreq, it would be pretty easy to add per drm_file counters to accumulate the per-submit results. We could even track per-context (submitqueue) for processes that have more than a single context, although not sure if that is useful.
Interesting tidbit is that the whole i915 work started from a customer request to expose just that (per context) in a form akin to getrusage(2). I think this kind of introspection capability is interesting but as it is driver specific territory it's only anecdotal for what this thread is concerned.
And I think there is probably some room for shared helper to print parts other than the per-engine stats (and maybe memory stats, although even that could be a shared implementation for some drivers).. with a driver callback for the non-generic parts, ie. something like:
drm_driver::show_client_stats(struct drm_file *, struct drm_printer *)but that can come later.
If there is a tool somewhere that displays this info, that would be useful for testing my implementation.
I have a patch to Intel specific intel_gpu_top (see https://patchwork.freedesktop.org/patch/468491/?series=98555&rev=1). I'll have a look to see how much work would it be to extract common bits into a library and write a quick agnostic tool using it.
Regards,
Tvrtko
On 21/01/2022 11:50, Tvrtko Ursulin wrote:
On 20/01/2022 16:44, Rob Clark wrote:
[snip]
If there is a tool somewhere that displays this info, that would be useful for testing my implementation.
I have a patch to Intel specific intel_gpu_top (see https://patchwork.freedesktop.org/patch/468491/?series=98555&rev=1). I'll have a look to see how much work would it be to extract common bits into a library and write a quick agnostic tool using it.
I factored out some code from intel_gpu_top in a quick and dirty attempt to make it generic and made a very rudimentary tools/gputop:
https://cgit.freedesktop.org/~tursulin/intel-gpu-tools/log/?h=gputop
If you manage to export the right fdinfo tags (basically https://patchwork.freedesktop.org/patch/468502/?series=92574&rev=6)*, with the only local addition I have being the optional "drm-engine-capacity-<str>: <uint>" tag, we may get lucky and tool might even work. Let me know when you try. If it will work you should see something like this:
DRM minor 0 PID NAME render copy video 3838 kwin_x11 |█ || || || | 327056 mpv | || ||▌ || | 327056 mpv |▌ || || || | 1 systemd |▍ || || || | 3884 plasmashell | || || || | 4794 krunner | || || || | 4836 thunderbird | || || || | 296733 GeckoMain | || || || |
Regards,
Tvrtko
*) Or for more reference this is how the i915 output looks like:
$ sudo cat /proc/7296/fdinfo/10 pos: 0 flags: 02100002 mnt_id: 26 ino: 501 drm-driver: i915 drm-pdev: 0000:00:02.0 drm-client-id: 22 drm-engine-render: 196329331 ns drm-engine-copy: 0 ns drm-engine-video: 0 ns drm-engine-capacity-video: 2 drm-engine-video-enhance: 0 ns
P.S. There is no AMD support in the current code, or nothing for memory either. Both can be added later.
Wow, nice.
Certainly +1 from my side to have that generalized, documented and uniform among all drivers.
Regards, Christian.
Am 25.01.22 um 11:24 schrieb Tvrtko Ursulin:
On 21/01/2022 11:50, Tvrtko Ursulin wrote:
On 20/01/2022 16:44, Rob Clark wrote:
[snip]
If there is a tool somewhere that displays this info, that would be useful for testing my implementation.
I have a patch to Intel specific intel_gpu_top (see https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork....). I'll have a look to see how much work would it be to extract common bits into a library and write a quick agnostic tool using it.
I factored out some code from intel_gpu_top in a quick and dirty attempt to make it generic and made a very rudimentary tools/gputop:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freed...
If you manage to export the right fdinfo tags (basically https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork...., with the only local addition I have being the optional "drm-engine-capacity-<str>: <uint>" tag, we may get lucky and tool might even work. Let me know when you try. If it will work you should see something like this:
DRM minor 0 PID NAME render copy video 3838 kwin_x11 |█ || || || | 327056 mpv | || ||▌ || | 327056 mpv |▌ || || || | 1 systemd |▍ || || || | 3884 plasmashell | || || || | 4794 krunner | || || || | 4836 thunderbird | || || || | 296733 GeckoMain | || || || |
Regards,
Tvrtko
*) Or for more reference this is how the i915 output looks like:
$ sudo cat /proc/7296/fdinfo/10 pos: 0 flags: 02100002 mnt_id: 26 ino: 501 drm-driver: i915 drm-pdev: 0000:00:02.0 drm-client-id: 22 drm-engine-render: 196329331 ns drm-engine-copy: 0 ns drm-engine-video: 0 ns drm-engine-capacity-video: 2 drm-engine-video-enhance: 0 ns
P.S. There is no AMD support in the current code, or nothing for memory either. Both can be added later.
Hi Rob,
On 25/01/2022 10:24, Tvrtko Ursulin wrote:
On 21/01/2022 11:50, Tvrtko Ursulin wrote:
On 20/01/2022 16:44, Rob Clark wrote:
[snip]
If there is a tool somewhere that displays this info, that would be useful for testing my implementation.
I have a patch to Intel specific intel_gpu_top (see https://patchwork.freedesktop.org/patch/468491/?series=98555&rev=1). I'll have a look to see how much work would it be to extract common bits into a library and write a quick agnostic tool using it.
I factored out some code from intel_gpu_top in a quick and dirty attempt to make it generic and made a very rudimentary tools/gputop:
https://cgit.freedesktop.org/~tursulin/intel-gpu-tools/log/?h=gputop
Have you managed to spend any time playing with this yet?
The only remaining open was Daniel's mild concern if vendor agnostic userspace is possible using the proposed spec. If you managed to wire up the compliant exports and gputop tool works I think that concern would be settled.
Regards,
Tvrtko
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Similar to AMD commit 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the infrastructure added in previous patches, we add basic client info and GPU engine utilisation for i915.
Example of the output:
pos: 0 flags: 0100002 mnt_id: 21 drm-driver: i915 drm-pdev: 0000:00:02.0 drm-client-id: 7 drm-engine-render: 9288864723 ns drm-engine-copy: 2035071108 ns drm-engine-video: 0 ns drm-engine-video-enhance: 0 ns
v2: * Update for removal of name and pid.
v3: * Use drm_driver.name.
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Cc: David M Nieto David.Nieto@amd.com Cc: Christian König christian.koenig@amd.com Cc: Daniel Vetter daniel@ffwll.ch Cc: Chris Healy cphealy@gmail.com Acked-by: Christian König christian.koenig@amd.com --- Documentation/gpu/drm-usage-stats.rst | 6 +++ Documentation/gpu/i915.rst | 27 ++++++++++ drivers/gpu/drm/i915/i915_driver.c | 3 ++ drivers/gpu/drm/i915/i915_drm_client.c | 73 ++++++++++++++++++++++++++ drivers/gpu/drm/i915/i915_drm_client.h | 4 ++ 5 files changed, 113 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index c669026be244..6952f8389d07 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -95,3 +95,9 @@ object belong to this client, in the respective memory region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' indicating kibi- or mebi-bytes. + +=============================== +Driver specific implementations +=============================== + +:ref:`i915-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index b7d801993bfa..29f412a0c3dc 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -708,3 +708,30 @@ The style guide for ``i915_reg.h``.
.. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h :doc: The i915 register macro definition style guide + +.. _i915-usage-stats: + +i915 DRM client usage stats implementation +========================================== + +The drm/i915 driver implements the DRM client usage stats specification as +documented in :ref:`drm-client-usage-stats`. + +Example of the output showing the implemented key value pairs and entirety of +the currenly possible format options: + +:: + + pos: 0 + flags: 0100002 + mnt_id: 21 + drm-driver: i915 + drm-pdev: 0000:00:02.0 + drm-client-id: 7 + drm-engine-render: 9288864723 ns + drm-engine-copy: 2035071108 ns + drm-engine-video: 0 ns + drm-engine-video-enhance: 0 ns + +Possible `drm-engine-` key names are: `render`, `copy`, `video` and +`video-enhance`. diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c index c9b18dadf828..bb8e621046d7 100644 --- a/drivers/gpu/drm/i915/i915_driver.c +++ b/drivers/gpu/drm/i915/i915_driver.c @@ -1755,6 +1755,9 @@ static const struct file_operations i915_driver_fops = { .read = drm_read, .compat_ioctl = i915_ioc32_compat_ioctl, .llseek = noop_llseek, +#ifdef CONFIG_PROC_FS + .show_fdinfo = i915_drm_client_fdinfo, +#endif };
static int diff --git a/drivers/gpu/drm/i915/i915_drm_client.c b/drivers/gpu/drm/i915/i915_drm_client.c index 91a8559bebf7..06dbd20ce763 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.c +++ b/drivers/gpu/drm/i915/i915_drm_client.c @@ -7,6 +7,11 @@ #include <linux/slab.h> #include <linux/types.h>
+#include <uapi/drm/i915_drm.h> + +#include <drm/drm_print.h> + +#include "gem/i915_gem_context.h" #include "i915_drm_client.h" #include "i915_gem.h" #include "i915_utils.h" @@ -68,3 +73,71 @@ void i915_drm_clients_fini(struct i915_drm_clients *clients) GEM_BUG_ON(!xa_empty(&clients->xarray)); xa_destroy(&clients->xarray); } + +#ifdef CONFIG_PROC_FS +static const char * const uabi_class_names[] = { + [I915_ENGINE_CLASS_RENDER] = "render", + [I915_ENGINE_CLASS_COPY] = "copy", + [I915_ENGINE_CLASS_VIDEO] = "video", + [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance", +}; + +static u64 busy_add(struct i915_gem_context *ctx, unsigned int class) +{ + struct i915_gem_engines_iter it; + struct intel_context *ce; + u64 total = 0; + + for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) { + if (ce->engine->uabi_class != class) + continue; + + total += intel_context_get_total_runtime_ns(ce); + } + + return total; +} + +static void +show_client_class(struct seq_file *m, + struct i915_drm_client *client, + unsigned int class) +{ + const struct list_head *list = &client->ctx_list; + u64 total = atomic64_read(&client->past_runtime[class]); + struct i915_gem_context *ctx; + + rcu_read_lock(); + list_for_each_entry_rcu(ctx, list, client_link) + total += busy_add(ctx, class); + rcu_read_unlock(); + + return seq_printf(m, "drm-engine-%s:\t%llu ns\n", + uabi_class_names[class], total); +} + +void i915_drm_client_fdinfo(struct seq_file *m, struct file *f) +{ + struct drm_file *file = f->private_data; + struct drm_i915_file_private *file_priv = file->driver_priv; + struct drm_i915_private *i915 = file_priv->dev_priv; + struct i915_drm_client *client = file_priv->client; + struct pci_dev *pdev = to_pci_dev(i915->drm.dev); + unsigned int i; + + /* + * ****************************************************************** + * For text output format description please see drm-usage-stats.rst! + * ****************************************************************** + */ + + seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name); + seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n", + pci_domain_nr(pdev->bus), pdev->bus->number, + PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); + seq_printf(m, "drm-client-id:\t%u\n", client->id); + + for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) + show_client_class(m, client, i); +} +#endif diff --git a/drivers/gpu/drm/i915/i915_drm_client.h b/drivers/gpu/drm/i915/i915_drm_client.h index 7416e18aa33c..d96d6a06302e 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.h +++ b/drivers/gpu/drm/i915/i915_drm_client.h @@ -57,6 +57,10 @@ static inline void i915_drm_client_put(struct i915_drm_client *client)
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients);
+#ifdef CONFIG_PROC_FS +void i915_drm_client_fdinfo(struct seq_file *m, struct file *f); +#endif + void i915_drm_clients_fini(struct i915_drm_clients *clients);
#endif /* !__I915_DRM_CLIENT_H__ */
On Thu, Jan 06, 2022 at 04:55:36PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Similar to AMD commit 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the infrastructure added in previous patches, we add basic client info and GPU engine utilisation for i915.
Example of the output:
pos: 0 flags: 0100002 mnt_id: 21 drm-driver: i915 drm-pdev: 0000:00:02.0 drm-client-id: 7 drm-engine-render: 9288864723 ns drm-engine-copy: 2035071108 ns drm-engine-video: 0 ns drm-engine-video-enhance: 0 ns
v2:
- Update for removal of name and pid.
v3:
- Use drm_driver.name.
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Cc: David M Nieto David.Nieto@amd.com Cc: Christian König christian.koenig@amd.com Cc: Daniel Vetter daniel@ffwll.ch Cc: Chris Healy cphealy@gmail.com Acked-by: Christian König christian.koenig@amd.com
Documentation/gpu/drm-usage-stats.rst | 6 +++ Documentation/gpu/i915.rst | 27 ++++++++++ drivers/gpu/drm/i915/i915_driver.c | 3 ++ drivers/gpu/drm/i915/i915_drm_client.c | 73 ++++++++++++++++++++++++++ drivers/gpu/drm/i915/i915_drm_client.h | 4 ++ 5 files changed, 113 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index c669026be244..6952f8389d07 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -95,3 +95,9 @@ object belong to this client, in the respective memory region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' indicating kibi- or mebi-bytes.
+=============================== +Driver specific implementations +===============================
+:ref:`i915-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index b7d801993bfa..29f412a0c3dc 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -708,3 +708,30 @@ The style guide for ``i915_reg.h``.
.. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h :doc: The i915 register macro definition style guide
+.. _i915-usage-stats:
+i915 DRM client usage stats implementation +==========================================
+The drm/i915 driver implements the DRM client usage stats specification as +documented in :ref:`drm-client-usage-stats`.
+Example of the output showing the implemented key value pairs and entirety of +the currenly possible format options:
s/currenly/currently/
lgtm, for the series
Reviewed-by: Umesh Nerlige Ramappa umesh.nerlige.ramappa@intel.com
Regards, Umesh
On 19/02/2022 00:51, Umesh Nerlige Ramappa wrote:
On Thu, Jan 06, 2022 at 04:55:36PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursulin@intel.com
Similar to AMD commit 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the infrastructure added in previous patches, we add basic client info and GPU engine utilisation for i915.
Example of the output:
pos: 0 flags: 0100002 mnt_id: 21 drm-driver: i915 drm-pdev: 0000:00:02.0 drm-client-id: 7 drm-engine-render: 9288864723 ns drm-engine-copy: 2035071108 ns drm-engine-video: 0 ns drm-engine-video-enhance: 0 ns
v2:
- Update for removal of name and pid.
v3:
- Use drm_driver.name.
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@intel.com Cc: David M Nieto David.Nieto@amd.com Cc: Christian König christian.koenig@amd.com Cc: Daniel Vetter daniel@ffwll.ch Cc: Chris Healy cphealy@gmail.com Acked-by: Christian König christian.koenig@amd.com
Documentation/gpu/drm-usage-stats.rst | 6 +++ Documentation/gpu/i915.rst | 27 ++++++++++ drivers/gpu/drm/i915/i915_driver.c | 3 ++ drivers/gpu/drm/i915/i915_drm_client.c | 73 ++++++++++++++++++++++++++ drivers/gpu/drm/i915/i915_drm_client.h | 4 ++ 5 files changed, 113 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index c669026be244..6952f8389d07 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -95,3 +95,9 @@ object belong to this client, in the respective memory region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' indicating kibi- or mebi-bytes.
+=============================== +Driver specific implementations +===============================
+:ref:`i915-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index b7d801993bfa..29f412a0c3dc 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -708,3 +708,30 @@ The style guide for ``i915_reg.h``.
.. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h :doc: The i915 register macro definition style guide
+.. _i915-usage-stats:
+i915 DRM client usage stats implementation +==========================================
+The drm/i915 driver implements the DRM client usage stats specification as +documented in :ref:`drm-client-usage-stats`.
+Example of the output showing the implemented key value pairs and entirety of +the currenly possible format options:
s/currenly/currently/
lgtm, for the series Reviewed-by: Umesh Nerlige Ramappa umesh.nerlige.ramappa@intel.com
Thanks Umesh!
There will be a small re-spin, mostly about adding drm-engine-capacity- tag which I needed for vendor agnostic gputop, and couple fixups. Some r-b's will need updating. I will copy you when sending it out.
Regards,
Tvrtko
dri-devel@lists.freedesktop.org
-
Christian König -
Daniel Vetter -
Rob Clark -
Tvrtko Ursulin -
Umesh Nerlige Ramappa