On 23/01/2017 11:50, Chris Wilson wrote:
On Mon, Jan 23, 2017 at 11:41:03AM +, Tvrtko Ursulin wrote:
On 23/01/2017 10:51, Chris Wilson wrote:
On Mon, Jan 23, 2017 at 10:43:10AM +, Tvrtko Ursulin wrote:
@@ -3285,6 +3291,7 @@ int i915_gem_object_set_cache_level(struct
On Mon, Jan 23, 2017 at 11:41:03AM +, Tvrtko Ursulin wrote:
>
> On 23/01/2017 10:51, Chris Wilson wrote:
> >On Mon, Jan 23, 2017 at 10:43:10AM +, Tvrtko Ursulin wrote:
> >>>@@ -3285,6 +3291,7 @@ int i915_gem_object_set_cache_level(struct
> >>>drm_i915_gem_object *obj,
> >>> ret
On 23/01/2017 10:51, Chris Wilson wrote:
On Mon, Jan 23, 2017 at 10:43:10AM +, Tvrtko Ursulin wrote:
@@ -3285,6 +3291,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
ret = i915_gem_object_wait(obj,
On Mon, Jan 23, 2017 at 10:43:10AM +, Tvrtko Ursulin wrote:
> >@@ -3285,6 +3291,7 @@ int i915_gem_object_set_cache_level(struct
> >drm_i915_gem_object *obj,
> > ret = i915_gem_object_wait(obj,
> >I915_WAIT_INTERRUPTIBLE |
> >
On 21/01/2017 09:25, Chris Wilson wrote:
We always try to do an unlocked wait before resorting to having a
blocking wait under the mutex - so we very rarely have to sleep under
the struct_mutex. However, when we do we want that wait to be as short
as possible as the struct_mutex is our BKL that
On la, 2017-01-21 at 09:25 +, Chris Wilson wrote:
> We always try to do an unlocked wait before resorting to having a
> blocking wait under the mutex - so we very rarely have to sleep under
> the struct_mutex. However, when we do we want that wait to be as short
> as possible as the
We always try to do an unlocked wait before resorting to having a
blocking wait under the mutex - so we very rarely have to sleep under
the struct_mutex. However, when we do we want that wait to be as short
as possible as the struct_mutex is our BKL that will stall the driver and
all clients.
