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.sha...@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
