[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:28:33PM +0100, 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).

Though that predates full-ppgtt (and even the recent aliasing-ppgtt
split). Time to start thinking about doing something similar for
contexts.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre