On 14/10/15 14:17, Chris Wilson wrote:
Since the beginning we have conflated the size of the global GTT with
that of the per-process context sizes. In recent times (gen8+), those
are no longer the same where the global GTT is limited to 2/4GiB but the
per-process GTT may be anything up to 256TiB. Userspace knows nothing of
this discrepancy and outside of one or two hacks, uses the getaperture
ioctl to determine the maximum size it can use. Let's leave that as
reporting the global GTT and use the context reporting method to
describe the per-process value (which naturally fallsback to reporting
the aliasing or global on older platforms, so userspace can always use
this method where available).
Testcase: igt/gem_userptr_blits/minor-normal-sync
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90065
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/i915_gem_context.c | 8 ++++++++
include/uapi/drm/i915_drm.h | 5 +++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index 339a9d628f1e..cecb156c6f76 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1087,6 +1087,14 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
case I915_CONTEXT_PARAM_NO_ZEROMAP:
args->value = ctx->flags & CONTEXT_NO_ZEROMAP;
break;
+ case I915_CONTEXT_PARAM_GTT_SIZE:
+ if (ctx->ppgtt)
+ args->value = ctx->ppgtt->base.total;
+ else if (to_i915(dev)->mm.aliasing_ppgtt)
+ args->value = to_i915(dev)->mm.aliasing_ppgtt->base.total;
+ else
+ args->value = to_i915(dev)->gtt.base.total;
+ break;
default:
ret = -EINVAL;
break;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 83f60f01dca2..3f334967aa1b 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1130,8 +1130,9 @@ struct drm_i915_gem_context_param {
__u32 ctx_id;
__u32 size;
__u64 param;
-#define I915_CONTEXT_PARAM_BAN_PERIOD 0x1
-#define I915_CONTEXT_PARAM_NO_ZEROMAP 0x2
+#define I915_CONTEXT_PARAM_BAN_PERIOD 0x1
+#define I915_CONTEXT_PARAM_NO_ZEROMAP 0x2
+#define I915_CONTEXT_PARAM_GTT_SIZE 0x3
__u64 value;
};
Implementation looks fine,
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
I have a slight unknown relating to how long would this ABI be useful.
If things are moving towards SVM, and the fact pre-gen8 platforms can
already use get_aperture, would that make it a bit short lived?
And get_aperture would even be a better place for this if PPGTT size
will always be the same for all clients.
Only if we consider that one day we might want to regulate available
address space available to clients (so implement also a setter for the
context param), then per-ctx makes sense. (If again, SVM does not make
this irrelevant.)
This address space limiting kind of sounds interesting, together with
the incoming GPU scheduling priorities, but then for the both I am not
sure if an appropriate mechanism could be constructed to use it in a
classical Unix sense, where you could set limits and inherit them from
parent to child. To construct some sort of a launcher with lower
priority / memory use.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
