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

[Chris Wilson]

On Wed, Jan 28, 2015 at 10:59:28AM +0100, Daniel Vetter wrote:
> On Mon, Jan 26, 2015 at 04:43:18AM -0800, Rodrigo Vivi wrote:
> > 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.
> > 
> > This is not quite what userspace wants to answer the question of whether
> > this batch will fit as fences are also required to meet severe alignment
> > constraints within the batch. For this purpose, a third conservative
> > estimate of largest fence available is also provided. For when userspace
> > needs more than one batch, we also provide the culmulative space
> > available for fences such that it has some additional guidance to how
> > much space it could allocate to fences. Conservatism still wins.
> > 
> > The patch also adds a debugfs file for convenient testing and reporting.
> > 
> > v2: The first object cannot end at offset 0, so we can use last==0 to
> > detect the empty list.
> > 
> > v3: Expand all values to 64bit, just in case.
> >     Report total mappable aperture size for userspace that cannot easily
> >     determine it by inspecting the PCI device.
> > 
> > v4: (Rodrigo) Fixed rebase conflicts.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
> 
> Do we have the libdrm patch for this too? Imo there's not much use in this
> if mesa remains broken, especially since this is for gen2/3 ... most DE
> use gl nowadays.

Mesa on gen2/3 is broken full stop as it cannot handle the full desktop
size anyway. Just like Broadwell.

There was a user ready to go and waiting.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre