Re: [Intel-gfx] [PATCH 05/26] drm/i915: Remove locking from i915_gem_object_prepare_read/write

2020-06-29 Thread Tvrtko Ursulin
On 23/06/2020 15:28, Maarten Lankhorst wrote: Execbuffer submission will perform its own WW locking, and we cannot rely on the implicit lock there. This also makes it clear that the GVT code will get a lockdep splat when multiple batchbuffer shadows need to be performed in the same instance,

Re: [Intel-gfx] [PATCH 05/26] drm/i915: Remove locking from i915_gem_object_prepare_read/write

2020-06-26 Thread Intel
On 6/23/20 4:28 PM, Maarten Lankhorst wrote: Execbuffer submission will perform its own WW locking, and we cannot rely on the implicit lock there. This also makes it clear that the GVT code will get a lockdep splat when multiple batchbuffer shadows need to be performed in the same instance,

[Intel-gfx] [PATCH 05/26] drm/i915: Remove locking from i915_gem_object_prepare_read/write

2020-06-23 Thread Maarten Lankhorst
Execbuffer submission will perform its own WW locking, and we cannot rely on the implicit lock there. This also makes it clear that the GVT code will get a lockdep splat when multiple batchbuffer shadows need to be performed in the same instance, fix that up. Signed-off-by: Maarten Lankhorst