[Intel-gfx] [PATCH] drm/i915: Wait and retry if there is no space in the aperture mappable area

Daniel Vetter daniel at ffwll.ch
Wed Oct 23 11:55:45 CEST 2013


On Wed, Oct 23, 2013 at 11:44 AM, Bloomfield, Jon
<jon.bloomfield at intel.com> wrote:
> Is calling i915_gem_evict_everything() actually dangerous ? Despite its name, it appears to only evict unpinned buffers. Or am I missing something ?
>
> What it does do is update the status of buffers which are no longer in use on the ring by calling i915_gem_retire_requests(). So from what I can tell (from a 10 minute trawl of the code admittedly) all this patch is doing is getting a more up to date view of the GTT demands so that we only fail with ENOSPC if there are no pinned buffers which can now be unpinned.
>
> It doesn't address our underlying issue - userspace should still handle ENOSPC gracefully. However it certainly seems to be improving things considerably, so is beneficial if it really is a safe thing to do.

We use evict_everything in the execbuf code to defragment the gtt. But
that's only beneficial because execbuffer needs to find space for
multiple buffers at once. For just binding one single buffer the
eviction code should scan all lists. Throwing in an additional
evict_everything on top won't help at all.

Of course if you throw in copious amounts of evict_everything once
you're in a bad spot the defragmentation this causes might help to get
out of that corner. But it really shouldn't help with preventing
SIGBUS in the first place. So I really wonder what exactly's going on
here. Can you perhaps distill a testcase and share it (preferrably as
an i-g-t patch ofc)?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list