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

[Tvrtko Ursulin]

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 at intel.com 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.

In that case for stolen we would add:

  stolen_size = dev_priv->gtt.stolen_size
  stolen_available = stolen_size - bios_reserved

(Bios_reserved would have to be stored in i915_gtt since it is currently 
local to i915_gem_init_stolen.)

Plus the ones you listed, mappable_size and ppgtt_size.

And the used/largest/fence/... ones go to debugfs.

Regards,

Tvrtko