On Wed, Jul 08, 2015 at 03:24:08PM +0100, Tvrtko Ursulin wrote: > > On 07/08/2015 02:53 PM, Chris Wilson wrote: > >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? > > It would make a more sensible ioctl if you think we could get away > with it. Hopefully no userspace tries to do anything smart with > aper_available_size today? I see one IGT user, gem_ctx_exec, which > probably isn't a blocker. Now that you mention it, we lie anyway there. The idea behind gem_ctx_exec is try and guage how much remaining global gtt space we need to fill with context objects - but important reservations of global gtt aren't even subtracted from the avail aperture space. There's also a use in sna when we run very close to the limit, we double check if the available space is enough. That's semi-sensible, certainly for the gen2-3 system that hit it most. Ok, so we get to keep aper_available_size. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
