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

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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@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?

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx