From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA370C433DF for ; Tue, 13 Oct 2020 11:08:34 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1B3A820659 for ; Tue, 13 Oct 2020 11:08:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="OjLB26Bn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B3A820659 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 06C626E8BA; Tue, 13 Oct 2020 11:08:33 +0000 (UTC) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by gabe.freedesktop.org (Postfix) with ESMTPS id 746C96E114 for ; Tue, 13 Oct 2020 11:08:31 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id f21so20504040wml.3 for ; Tue, 13 Oct 2020 04:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=uvxObDwTo5Y8F/KuyP+1hkA480rLi769JHi4wPHoyZo=; b=OjLB26BnBY0bTsdHD3EzrtKyC81oM/0JTZCn6CLgyXf7zcDUfy5vEiXi3UDSzVmHDi +28SDYfaM8aC9c0gvCjcQjZSkVZiSn1tj4DX9sZ7XtG7z0O9zDzWRQtW0bl4JEUVlmj6 oHncYXBeGhKdacVIldQq+ga8Rp+OxaRjm6pSI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=uvxObDwTo5Y8F/KuyP+1hkA480rLi769JHi4wPHoyZo=; b=saaazTJeBcca6d7+WuUaJ8ce7vbnB1CFALRPrS9+dBvfJ/zACedWlbauAmtNjfOV7s GwnN40PhQErAT5U67FpNc4LJH8HDCFgwu87DkvgR395U9Rqi7vwfjZFx2d8tSEdcWsnQ eDHT0GoUpPlUZzOdzomlYmr9BnjMG+KhXuV6b7V8iJ+pibMSOw3yLZqo07sGBy0eLtSj jf8rPQA6v1sFWN1rLeg0Npx2RfYU55RfqBJbaBCG4/ndc+Qig3dSqa/IguqwedK0R3H8 D7Vrnn2vXMSi4sUXseWJtZjUC6Af33qpYsFvCd6h9JHlhHYVjfB0DpGZQp02Cp1EtR2p gWxg== X-Gm-Message-State: AOAM530o8MNf7I2LpNYK1M3As1+doAuJ/b4HLnhm8MF/c9Zajtb8hJDr 76ddBKtnZVHPQT9sgNTooIvuBA== X-Google-Smtp-Source: ABdhPJwdxWAoTqe7At2F5tTQxz1+7Sey1hlKtS1VILSfOid9lZqdcUgzZZ28B6xcbL7mDDIeJVxKpg== X-Received: by 2002:a1c:ddc2:: with SMTP id u185mr15579789wmg.21.1602587309567; Tue, 13 Oct 2020 04:08:29 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id v11sm13304289wml.26.2020.10.13.04.08.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2020 04:08:28 -0700 (PDT) Date: Tue, 13 Oct 2020 13:08:26 +0200 From: Daniel Vetter To: Rob Clark Subject: Re: [PATCH v2 22/22] drm/msm: Don't implicit-sync if only a single ring Message-ID: <20201013110826.GD438822@phenom.ffwll.local> Mail-Followup-To: Rob Clark , dri-devel , Rob Clark , Sean Paul , David Airlie , "open list:DRM DRIVER FOR MSM ADRENO GPU" , "open list:DRM DRIVER FOR MSM ADRENO GPU" , open list References: <20201012020958.229288-1-robdclark@gmail.com> <20201012020958.229288-23-robdclark@gmail.com> <20201012144018.GB438822@phenom.ffwll.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Clark , David Airlie , Sean Paul , open list , dri-devel , "open list:DRM DRIVER FOR MSM ADRENO GPU" , "open list:DRM DRIVER FOR MSM ADRENO GPU" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Oct 12, 2020 at 08:07:38AM -0700, Rob Clark wrote: > On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote: > > > > On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > Any cross-device sync use-cases *must* use explicit sync. And 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). > > > > Uh does this mean msm is broken on dri2/3 and wayland? Or I'm I just > > confused by your commit message? > > No, I don't think so. If there is only a single priority level > ringbuffer (ie. no preemption to higher priority ring) then everything > is inherently FIFO order. Well eventually you get a scheduler I guess/hope :-) > For cases where we are sharing buffers with something external to drm, > explicit sync will be used. And we don't implicit sync with display, > otherwise x11 (frontbuffer rendering) would not work Uh now I'm even more confused. The implicit sync fences in dma_resv are kinda for everyone. That's also why dma_resv with the common locking approach is a useful idea. So display should definitely support implicit sync, and iirc msm does have the helper hooked up. Wrt other subsystems, I guess passing dma_fence around somehow doesn't fit into v4l (the patches never landed), so v4l doesn't do any kind of sync right now. But this could be fixed. Not sure what else is going on. So I guess I still have no idea why you put that into the commit message. btw for what you're trying to do yourself, the way to do this is to allocate a fence timeline for your engine, compare fences, and no-op them all out if their own the same timeline. -Daniel > > BR, > -R > > > Since for these protocols we do expect implicit sync accross processes to > > work. Even across devices (and nvidia have actually provided quite a bunch > > of patches to make this work in i915 - ttm based drivers get this right, > > plus dumb scanout drivers using the right helpers also get this all > > right). > > -Daniel > > > > > > > > Signed-off-by: Rob Clark > > > --- > > > 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 3151a0ca8904..c69803ea53c8 100644 > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > > > @@ -277,7 +277,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; > > > > > > @@ -297,7 +297,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, > > > @@ -768,7 +768,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; > > > > > > -- > > > 2.26.2 > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel