[Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space

[Chris Wilson]

On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote:
> 
> On 07/08/2015 02:28 PM, Chris Wilson wrote:
> >On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote:
> >>
> >>Hi,
> >>
> >>On 07/08/2015 07:51 AM, ankitprasad.r.sharma at intel.com wrote:
> >>>From: Rodrigo Vivi <rodrigo.vivi at intel.com>
> >>>
> >>>When constructing a batchbuffer, it is sometimes crucial to know the
> >>>largest hole into which we can fit a fenceable buffer (for example when
> >>>handling very large objects on gen2 and gen3). This depends on the
> >>>fragmentation of pinned buffers inside the aperture, a question only the
> >>>kernel can easily answer.
> >>>
> >>>This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
> >>>include a couple of new fields in its reply to userspace - the total
> >>>amount of space available in the mappable region of the aperture and
> >>>also the single largest block available.
> >>
> >>Since whatever this returns is a transient number is this really
> >>that useful? There are no guarantees that by the time caller tries
> >>to act on it it will still be valid.
> >
> >Yes. My use case is actually after a failure to capture debug
> >information. I don't anticipate frequent calls to get_aperture (usually
> >just a single call during early init).
> 
> Should it better go to debugfs then?

Hmm, I could accept that. In such a scenario, I would suggest we ignore
the avail_aperture_space field all together, just report it as max (or
whatever) and simply add fields for max stolen, max mappable, max ggtt
(already present) and max ppgtt. (Rather than continue trying to kill
multiple birds with one stone, where 99.9% of users don't want the
overhead.)

Move the current patch series into debugfs.c and just add the limits to
get_aperture?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre