Am 17.05.21 um 22:36 schrieb Daniel Vetter:
On Mon, May 17, 2021 at 04:11:27PM +0200, Christian König wrote:
Add usage flags for shared fences and improve the documentation.
This allows driver to better specify what shared fences
are doing with the resource.
Signed-off-by: Christian König <christian.koenig@xxxxxxx>
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 16b869d9b1d6..c9bbc4630afc 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -700,7 +700,7 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
return ret;
}
- dma_resv_add_shared_fence(bo->base.resv, fence);
+ dma_resv_add_shared(bo->base.resv, fence, DMA_RESV_USAGE_RW);
Entirely aside, but I ended up scratching my head a lot for why exactly
this here is a shared fence, and why that's ok. Since just looking at this
it seems like waiting for the memory allocation to actually be owned by
this driver is optional.
Is this ok because the next thing we'll do is a move, which will then set
the exclusive fence here. Which will then wait on the shared one here, so
it doesn't matter? Or well, allows us to pipeline the eviction of ttm_man
against whatever might be currently keeping the bo busy in it's current
place?
Yes, exactly that.
We just need to make sure that the new BO location isn't used before the
fence is completed, but we can't use the exclusive slot because we have
no guarantee at all that the move fence signals in the right order.
Regards,
Christian.
Might be good candidate to explain this in a comment or something like
that.
-Daniel
