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

[Daniel Vetter]

On Fri, Nov 1, 2013 at 5:56 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> So here's my idea to solve this for real:
> - split long-term pinned objects into two classes: Those that might
> need to be access through the mappable gtt mmio window (like scanout
> buffers) and those that don't (like hw contexts).
> - Pin objects that are never accessed through the mappable gtt by the
> cpu to the unmappable part of the gtt. This will get rid of all the hw
> contexts causing havoc by sitting in the middle of the mappable gtt
> due to bad luck.
> - Restrict all other pinned objects to [0, mappable_size / 2]. This
> will ensure that the range [mappable_size / 2, mappable] can always be
> evicted. Add some vicious checks to the code to make sure we never
> stumble over a pinned object in there. Also, expose this value to
> userspace as the guaranteed upper limit for gtt mmaps.
>
> Unfortunately we can't enforce this when creating the mapping since
> old userspace didn't bother with this, and most often (if you never do
> a modeset at least) it works _really_ well.
>
> Of course we need solid testcases to make sure we don't break this
> again. Luckily the gtt allocater is bottom-up and fully predictable if
> nothing else is running (which is the default assumption for i-g-t
> tests). So we need the following:
> - two objects A1/A2 of size gtt_mappable / 3
> - some means to trick the kernel into pinning an object of the class
> we want to test. We need 2 such objects B1, B2.
>
> 1. fault in object A1 through cpu gtt access.
> 2. trick kernel into pinning B1.
> 3. fault in object A2 through cpu gtt access.
> 4. trick kernel into pinning B2.
> 5. Try to fault in a new object with gtt cpu access of size mappable/2.
>
> Now we have perfectly fragemented the gtt and there's no room for an
> object of size mappable/2. But if we restrict pinned objects it will
> work.
>
> Repeat the above test for all classes of pinned objects (hw context,
> scanout buffers, cursors, ...).
>
> I think this is conceptually the simplest change that actually gives
> us real guarantees. And it doesn't change anything fundamentally with
> how gem works (as opposed to the pinned buffer eviction logic) and so
> should be much less tricky to implement.
>
> Please poke holes into the plan.

One problem of the above approach is that we the unmappable pinned bo
will sit uncomfortably near to the middle of the gtt. Which could be a
problem on platforms without real ppgtt (currently all, soon only
older stuff) and userspace assuming it can map 1G textures for gpu
access. We probably need to allocate pinned unmappable bos top-down.
Ben's ppgtt patches already has teh infrastructure for that, but that
means we'll have to add a bit more testing for interactions between
pinning ppgtt pdes and hw contexts. Might be that we need a bit more
alignment constraints ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch