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@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). 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
