On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: > > Hi, > > On 07/08/2015 07:51 AM, ankitprasad.r.sharma@xxxxxxxxx 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
