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

[Chris Wilson]

On Wed, Jul 08, 2015 at 03:24:08PM +0100, Tvrtko Ursulin wrote:
> 
> On 07/08/2015 02:53 PM, Chris Wilson wrote:
> >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?
> 
> It would make a more sensible ioctl if you think we could get away
> with it. Hopefully no userspace tries to do anything smart with
> aper_available_size today? I see one IGT user, gem_ctx_exec, which
> probably isn't a blocker.

Now that you mention it, we lie anyway there. The idea behind
gem_ctx_exec is try and guage how much remaining global gtt space we
need to fill with context objects - but important reservations of global
gtt aren't even subtracted from the avail aperture space.

There's also a use in sna when we run very close to the limit, we double
check if the available space is enough. That's semi-sensible, certainly
for the gen2-3 system that hit it most.

Ok, so we get to keep aper_available_size.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre