Re: [PATCH] drm/ttm: Explain why ttm_bo_add_move_fence uses a shared slot

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, May 19, 2021 at 12:43:49PM +0200, Christian König wrote:
> Am 19.05.21 um 10:24 schrieb Daniel Vetter:
> > Motivated because I got confused and Christian confirmed why this
> > works. I think this is non-obvious enough that it merits a slightly
> > longer comment.
> > 
> > Cc: Christian König <ckoenig.leichtzumerken@gmail.com>
> > Cc: Christian Koenig <christian.koenig@amd.com>
> > Cc: Huang Rui <ray.huang@amd.com>
> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> Reviewed-by: Christian König <christian.koenig@amd.com>

Applied to drm-misc-next, thanks for reviewing.
-Daniel

> 
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index ca1b098b6a56..51a94fd63bd7 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -682,7 +682,9 @@ int ttm_mem_evict_first(struct ttm_device *bdev,
> >   }
> >   /*
> > - * Add the last move fence to the BO and reserve a new shared slot.
> > + * Add the last move fence to the BO and reserve a new shared slot. We only use
> > + * a shared slot to avoid unecessary sync and rely on the subsequent bo move to
> > + * either stall or use an exclusive fence respectively set bo->moving.
> >    */
> >   static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
> >   				 struct ttm_resource_manager *man,
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch