On Fri, Oct 16, 2015 at 05:34:55PM +0100, Tvrtko Ursulin wrote: > > 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 Probably also needs updates to the getparam testcase. > >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> Queued for -next, thanks for the patch. -Daniel > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
