From: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx>
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 set of patches 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 patches also support for getting total size and available size of the
stolen region as well as single largest block available in the stolen region.
It also adds a debugfs file for convenient testing and reporting.
v2: Rebased to the latest drm-intel-nightly
Ankitprasad Sharma (1):
drm/i915: Extend GET_APERTURE ioctl to report size of the stolen
region
Rodrigo Vivi (1):
drm/i915: Extend GET_APERTURE ioctl to report available map space
drivers/gpu/drm/i915/i915_debugfs.c | 33 +++++++++
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem.c | 123 +++++++++++++++++++++++++++++++--
drivers/gpu/drm/i915/i915_gem_stolen.c | 35 ++++++++++
include/uapi/drm/i915_drm.h | 40 +++++++++++
5 files changed, 230 insertions(+), 4 deletions(-)
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
