On 13/02/2018 13:46, Chris Wilson wrote:
Quoting Chris Wilson (2018-02-13 13:45:33)
Quoting Tvrtko Ursulin (2018-02-13 13:42:03)
On 12/02/2018 21:11, Chris Wilson wrote:
When we need to rebind the vma into the global GTT for snb, we need to
drop the current reloc_cache as it will be holding
Quoting Chris Wilson (2018-02-13 13:45:33)
> Quoting Tvrtko Ursulin (2018-02-13 13:42:03)
> >
> > On 12/02/2018 21:11, Chris Wilson wrote:
> > > When we need to rebind the vma into the global GTT for snb, we need to
> > > drop the current reloc_cache as it will be holding a kmap_atomic() and
> > >
Quoting Tvrtko Ursulin (2018-02-13 13:42:03)
>
> On 12/02/2018 21:11, Chris Wilson wrote:
> > When we need to rebind the vma into the global GTT for snb, we need to
> > drop the current reloc_cache as it will be holding a kmap_atomic() and
> > we may need to sleep for i915_vma_bind(). In practice,
On 12/02/2018 21:11, Chris Wilson wrote:
When we need to rebind the vma into the global GTT for snb, we need to
drop the current reloc_cache as it will be holding a kmap_atomic() and
we may need to sleep for i915_vma_bind(). In practice, this is not an
issue as we already hold an rpm reference f
When we need to rebind the vma into the global GTT for snb, we need to
drop the current reloc_cache as it will be holding a kmap_atomic() and
we may need to sleep for i915_vma_bind(). In practice, this is not an
issue as we already hold an rpm reference for the execbuffer, but with
tighter error ch
