Re: [RFC PATCH 34/42] drm/i915/query: Expose memory regions through the query uAPI

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Chris Wilson (2019-02-14 16:33:55)
> Quoting Chris Wilson (2019-02-14 16:31:13)
> > Quoting Matthew Auld (2019-02-14 14:57:32)
> > >  int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
> > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > index 26d2274b5d2b..5a102a5cb415 100644
> > > --- a/include/uapi/drm/i915_drm.h
> > > +++ b/include/uapi/drm/i915_drm.h
> > > @@ -1744,6 +1744,7 @@ struct drm_i915_perf_oa_config {
> > >  struct drm_i915_query_item {
> > >         __u64 query_id;
> > >  #define DRM_I915_QUERY_TOPOLOGY_INFO    1
> > > +#define DRM_I915_QUERY_MEMREGION_INFO   3
> > 
> > Ahem.
> > 
> > >         /*
> > >          * When set to zero by userspace, this is filled with the size of the
> > > @@ -1832,7 +1833,6 @@ struct drm_i915_query_topology_info {
> > >          * Offset in data[] at which the EU masks are stored.
> > >          */
> > >         __u16 eu_offset;
> > > -
> > >         /*
> > >          * Stride at which each of the EU masks for each subslice are stored.
> > >          */
> > > @@ -1841,6 +1841,44 @@ struct drm_i915_query_topology_info {
> > >         __u8 data[];
> > >  };
> > >  
> > > +struct drm_i915_memory_region_info {
> > > +
> > > +       /** Base type of a region
> > > +        */
> > > +#define I915_SYSTEM_MEMORY         0
> > > +#define I915_DEVICE_MEMORY         1
> > > +
> > > +       /** The region id is encoded in a layout which makes it possible to
> > > +        *  retrieve the following information:
> > > +        *
> > > +        *  Base type: log2(ID >> 16)
> > > +        *  Instance:  log2(ID & 0xffff)
> > > +        */
> > > +       __u32 id;
> > > +
> > > +       /** Reserved field. MBZ */
> > > +       __u32 rsvd0;
> > > +
> > > +       /** Unused for now. MBZ */
> > > +       __u64 flags;
> > > +
> > > +       __u64 size;
> > > +
> > > +       /** Reserved fields must be cleared to zero. */
> > > +       __u64 rsvd1[4];
> > > +};
> > 
> > If you were to apply this to stolen memory as an example, can you spot
> > how much information is missing?
> > 
> > Userspace would need to know total size, largest allocation chunk (i.e
> > largest object), rough estimate of availability, and most importantly a
> > list of API that is not allowed (such as CPU mmap, fencing). There's
> > without a doubt more that would be needed to actually wire it up to Vk.
> 
> Cross-process/ppgtt and cross-device sharing for example...

Another concept along the lines of MAP_PRIVATE above, is pure scratch. A
WO memory region that is not guaranteed to retain its state between
execution and is never swapped out but zapped under pressure. The use
being for things like kernel scratch allocations (for register spilling
and whatnot). Though small in the grand scheme of things, a context may
need 10+MiB of scratch (since even a small amount required per-thread
becomes a large amount) per stage.

I'm just looking to see what possibilities we may explore :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx