[Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
Chris Wilson
chris at chris-wilson.co.uk
Wed Jul 8 06:28:33 PDT 2015
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).
-Chrs
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list