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@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). > > 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? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
