[Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

[Chris Wilson]

On Thu, Apr 21, 2016 at 03:04:52PM +0100, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 20/04/16 12:17, ankitprasad.r.sharma at intel.com wrote:
> >+	mutex_unlock(&dev->struct_mutex);
> >+
> >+	seq_printf(m, "Total size of the GTT: %llu bytes\n",
> >+		   arg.aper_size);
> >+	seq_printf(m, "Available space in the GTT: %llu bytes\n",
> >+		   arg.aper_available_size);
> >+	seq_printf(m, "Total space in the mappable aperture: %llu bytes\n",
> >+		   arg.map_total_size);
> >+	seq_printf(m, "Available space in the mappable aperture: %llu bytes\n",
> >+		   map_space);
> >+	seq_printf(m, "Single largest space in the mappable aperture: %llu bytes\n",
> >+		   map_largest);
> >+	seq_printf(m, "Available space for fences: %llu bytes\n",
> >+		   fence_space);
> >+	seq_printf(m, "Single largest fence available: %llu bytes\n",
> >+		   fence_largest);
> >+
> >+	return 0;
> >+}
> >+
> 
> In general I find this a lot of code for a feature of questionable
> utility. As such I would prefer someone really stated the need for
> this and explained how it really is useful - even though whetever
> number they get from this may be completely irrelevant by the time
> it is acted upon.

Yes, with the exception of the size of the mappable aperture, this is
really is debug info. It will get automatically dumped by userspace
when it sees an ENOSPC, and that may prove enough to solve the riddle of
why it failed. However, this information is terrible outdated and now
longer of such relevance.

As for the mappable aperture size, there has been a request many years
ago! could we provide it without resorting to a privilege operation. I
guess by know that request has died out - but there is still the issue
with libpciassess that make it unsuitable for use inside a library where
one may want to avoid it and use a simple ioctl on the device you
already have open.

Yes, it is meh.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre