[Intel-gfx] [PATCH 1/2] drm/i915: Defer assignment of obj->gtt_space until after all possible mallocs
Chris Wilson
chris at chris-wilson.co.uk
Wed Nov 21 14:15:24 CET 2012
On Wed, 21 Nov 2012 14:11:34 +0100, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Nov 21, 2012 at 01:04:03PM +0000, Chris Wilson wrote:
> > As we may invoke the shrinker whilst trying to allocate memory to hold
> > the gtt_space for this object, we need to be careful not to mark the
> > drm_mm_node as activated (by assigning it to this object) before we
> > have finished our sequence of allocations.
> >
> > Reported-by: Imre Deak <imre.deak at gmail.com>
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
>
> > @@ -3449,11 +3443,16 @@ i915_gem_object_pin(struct drm_i915_gem_object *obj,
> > }
> >
> > if (obj->gtt_space == NULL) {
> > + struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> > +
> > ret = i915_gem_object_bind_to_gtt(obj, alignment,
> > map_and_fenceable,
> > nonblocking);
> > if (ret)
> > return ret;
> > +
> > + if (!dev_priv->mm.aliasing_ppgtt)
> > + i915_gem_gtt_bind_object(obj, obj->cache_level);
>
> Spurious hunk?
Not really, I need to reorder the bind_object until after the assignment
of obj->gtt_space and upon reflection it looked better if I did the bind
there next to its compadre then amongst the assignments in the tail of
bind_to_gtt(). Of course, this means that bind_to_gtt is now a grand
misnomer.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list