On Tue, Jul 6, 2021 at 2:47 PM Matthew Auld matthew.william.auld@gmail.com wrote:
On Tue, 6 Jul 2021 at 11:12, Daniel Vetter daniel.vetter@ffwll.ch wrote:
We're lifting, or well, clarifying that the restriction that shared fences have to be strictly after the exclusive one doesn't apply anymore.
So adjust the code to always also wait for the exclusive fence.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Cc: "Thomas Hellström" thomas.hellstrom@linux.intel.com Cc: Jason Ekstrand jason@jlekstrand.net
drivers/gpu/drm/i915/i915_sw_fence.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c b/drivers/gpu/drm/i915/i915_sw_fence.c index 91711a46b1c7..271d321cea83 100644 --- a/drivers/gpu/drm/i915/i915_sw_fence.c +++ b/drivers/gpu/drm/i915/i915_sw_fence.c @@ -601,10 +601,10 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence *fence, for (i = 0; i < count; i++) dma_fence_put(shared[i]); kfree(shared);
} else {excl = dma_resv_get_excl_unlocked(resv); }
excl = dma_resv_get_excl_unlocked(resv);The dma_resv_get_fences() call looks like it already fishes out the exclusive fence. Does this not leak the extra ref now?
Oh right I overlooked this, we already pick up the exclusive fence unconditionally. Control flow here was a bit too clever for my parser. I'll drop this patch in the next round. -Daniel
if (ret >= 0 && excl) { pending = i915_sw_fence_await_dma_fence(fence, excl,-- 2.32.0
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx