All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Rob Clark <robdclark@gmail.com>, dri-devel@lists.freedesktop.org
Cc: Rob Clark <robdclark@chromium.org>,
	David Airlie <airlied@linux.ie>,
	linux-arm-msm@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>,
	Sean Paul <sean@poorly.run>,
	"Kristian H . Kristensen" <hoegsberg@google.com>,
	freedreno@lists.freedesktop.org
Subject: Re: [PATCH v4 23/23] drm/msm: Don't implicit-sync if only a single ring
Date: Fri, 23 Oct 2020 20:20:02 +0200	[thread overview]
Message-ID: <d0fb714b99f13bea6000ecd17fba324433782ae5.camel@pengutronix.de> (raw)
In-Reply-To: <20201023165136.561680-24-robdclark@gmail.com>

On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> If there is only a single ring (no-preemption), everything is FIFO order
> and there is no need to implicit-sync.
> 
> Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> is undefined when fences are not used to synchronize buffer usage across
> contexts (which is the only case where multiple different priority rings
> could come into play).

Really, doesn't this break cross-device implicit sync? Okay, you may
not have many peripherals that rely on implicit sync on devices where
Adreno is usually found, but it seems rather heavy-handed.

Wouldn't it be better to only ignore fences from your own ring context
in the implicit sync, like we do in the common DRM scheduler
(drm_sched_dependency_optimized)?

Regards,
Lucas

> Signed-off-by: Rob Clark <robdclark@chromium.org>
> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
> ---
>  drivers/gpu/drm/msm/msm_gem_submit.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
> index d04c349d8112..b6babc7f9bb8 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -283,7 +283,7 @@ static int submit_lock_objects(struct msm_gem_submit *submit)
>  	return ret;
>  }
>  
> -static int submit_fence_sync(struct msm_gem_submit *submit, bool no_implicit)
> +static int submit_fence_sync(struct msm_gem_submit *submit, bool implicit_sync)
>  {
>  	int i, ret = 0;
>  
> @@ -303,7 +303,7 @@ static int submit_fence_sync(struct msm_gem_submit *submit, bool no_implicit)
>  				return ret;
>  		}
>  
> -		if (no_implicit)
> +		if (!implicit_sync)
>  			continue;
>  
>  		ret = msm_gem_sync_object(&msm_obj->base, submit->ring->fctx,
> @@ -774,7 +774,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
>  	if (ret)
>  		goto out;
>  
> -	ret = submit_fence_sync(submit, !!(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> +	ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> +			!(args->flags & MSM_SUBMIT_NO_IMPLICIT));
>  	if (ret)
>  		goto out;
>  


WARNING: multiple messages have this Message-ID (diff)
From: Lucas Stach <l.stach@pengutronix.de>
To: Rob Clark <robdclark@gmail.com>, dri-devel@lists.freedesktop.org
Cc: Rob Clark <robdclark@chromium.org>,
	freedreno@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
	linux-arm-msm@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>,
	"Kristian H . Kristensen" <hoegsberg@google.com>,
	Sean Paul <sean@poorly.run>
Subject: Re: [PATCH v4 23/23] drm/msm: Don't implicit-sync if only a single ring
Date: Fri, 23 Oct 2020 20:20:02 +0200	[thread overview]
Message-ID: <d0fb714b99f13bea6000ecd17fba324433782ae5.camel@pengutronix.de> (raw)
In-Reply-To: <20201023165136.561680-24-robdclark@gmail.com>

On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> If there is only a single ring (no-preemption), everything is FIFO order
> and there is no need to implicit-sync.
> 
> Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> is undefined when fences are not used to synchronize buffer usage across
> contexts (which is the only case where multiple different priority rings
> could come into play).

Really, doesn't this break cross-device implicit sync? Okay, you may
not have many peripherals that rely on implicit sync on devices where
Adreno is usually found, but it seems rather heavy-handed.

Wouldn't it be better to only ignore fences from your own ring context
in the implicit sync, like we do in the common DRM scheduler
(drm_sched_dependency_optimized)?

Regards,
Lucas

> Signed-off-by: Rob Clark <robdclark@chromium.org>
> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
> ---
>  drivers/gpu/drm/msm/msm_gem_submit.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
> index d04c349d8112..b6babc7f9bb8 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -283,7 +283,7 @@ static int submit_lock_objects(struct msm_gem_submit *submit)
>  	return ret;
>  }
>  
> -static int submit_fence_sync(struct msm_gem_submit *submit, bool no_implicit)
> +static int submit_fence_sync(struct msm_gem_submit *submit, bool implicit_sync)
>  {
>  	int i, ret = 0;
>  
> @@ -303,7 +303,7 @@ static int submit_fence_sync(struct msm_gem_submit *submit, bool no_implicit)
>  				return ret;
>  		}
>  
> -		if (no_implicit)
> +		if (!implicit_sync)
>  			continue;
>  
>  		ret = msm_gem_sync_object(&msm_obj->base, submit->ring->fctx,
> @@ -774,7 +774,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
>  	if (ret)
>  		goto out;
>  
> -	ret = submit_fence_sync(submit, !!(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> +	ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> +			!(args->flags & MSM_SUBMIT_NO_IMPLICIT));
>  	if (ret)
>  		goto out;
>  

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-10-23 18:20 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23 16:51 [PATCH v4 00/23] drm/msm: de-struct_mutex-ification Rob Clark
2020-10-23 16:51 ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 01/23] drm/msm: Fix a couple incorrect usages of get_vaddr_active() Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 02/23] drm/msm/gem: Add obj->lock wrappers Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 03/23] drm/msm/gem: Rename internal get_iova_locked helper Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 04/23] drm/msm/gem: Move prototypes to msm_gem.h Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 05/23] drm/msm/gem: Add some _locked() helpers Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 06/23] drm/msm/gem: Move locking in shrinker path Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 07/23] drm/msm/submit: Move copy_from_user ahead of locking bos Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 20:59   ` kernel test robot
2020-10-23 16:51 ` [PATCH v4 08/23] drm/msm: Do rpm get sooner in the submit path Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 09/23] drm/msm/gem: Switch over to obj->resv for locking Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 10/23] drm/msm: Use correct drm_gem_object_put() in fail case Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 11/23] drm/msm: Drop chatty trace Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 12/23] drm/msm: Move update_fences() Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 13/23] drm/msm: Add priv->mm_lock to protect active/inactive lists Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 14/23] drm/msm: Document and rename preempt_lock Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 15/23] drm/msm: Protect ring->submits with it's own lock Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 16/23] drm/msm: Refcount submits Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 17/23] drm/msm: Remove obj->gpu Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 18/23] drm/msm: Drop struct_mutex from the retire path Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 19/23] drm/msm: Drop struct_mutex in free_object() path Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 20/23] drm/msm: Remove msm_gem_free_work Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 21/23] drm/msm: Drop struct_mutex in madvise path Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 22/23] drm/msm: Drop struct_mutex in shrinker path Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 16:51 ` [PATCH v4 23/23] drm/msm: Don't implicit-sync if only a single ring Rob Clark
2020-10-23 16:51   ` Rob Clark
2020-10-23 18:20   ` Lucas Stach [this message]
2020-10-23 18:20     ` Lucas Stach
2020-10-24  3:49     ` Rob Clark
2020-10-24  3:49       ` Rob Clark
2020-10-26  9:34       ` Daniel Vetter
2020-10-26  9:34         ` Daniel Vetter
2020-10-29 16:14         ` Daniel Vetter
2020-10-29 16:14           ` Daniel Vetter
2020-10-29 16:59           ` Rob Clark
2020-10-29 16:59             ` Rob Clark
2020-10-29 18:22             ` Daniel Vetter
2020-10-29 18:22               ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d0fb714b99f13bea6000ecd17fba324433782ae5.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=hoegsberg@google.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.