Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp57619pxx; Mon, 26 Oct 2020 03:18:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5E6OG60f5VVv8jic6QeLNJuvKOvmZw5zy7cOXUWVDpG2fA6Nf9p51an7C/HWBtZyQ9Ser X-Received: by 2002:a17:906:3852:: with SMTP id w18mr14560747ejc.551.1603707498516; Mon, 26 Oct 2020 03:18:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603707498; cv=none; d=google.com; s=arc-20160816; b=fZ9QsxzsO5ewq6YO1IyP75weXaFtAiPZc2bhBgp7mE9ySQ0AKTliXIGaNaClm5Bct9 TE7DOJ9wv+svIthvF8CToDdBzCB28NABTW6kSqElM1FGVAVt8QH3lYvGZDKHnXVGIJ+m lAwpHv5zePSDOfKZUNi27x2q1KtfuwGhLb9fFRtJPhcuPS1p9Jk62NorC0oVY5n+OJa8 +O7MAesKbkamyZUOFAfQLbfFcP9a/HnC943khBS0xTLxsOvkOMm8+g1St4KIr1zPypDb A/PrDnz34B8F1dmuFgko/tmMLWedLpkWc6qbGawihdhh9e/XGwFDhc2KO0D7DLJmx6ev YXYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:mail-followup-to:message-id:subject:cc:to:from:date :dkim-signature; bh=gYzieEkyuY5GK4uIKGUgpkX8O/MjJBNKsXAywCS/qUs=; b=JGLHLMM7p9Q72LsmvZdzPihv50v4TMTa4LmP1yFkmFBm2Zr4Snjyi13ZQZa9VTUgUo Uxz6dBv7/AjoLGTbARng4MNVZZoC/Ie4zLTcluHaZPRLiYt3OVmavDp1m+wc8DMTO6LK esbA5kp590exa2QOluuklLo63T3ZXF27zqRPwb8wPv2VZBlLjxBt4+pR62X7Y7KuS51r RoejVm4VcnxT8BUsohMwRxcz2QbCW0kU3rhKNP7NNuTBY9si2QmAHls+gGc+tSY8HyNr F+NWUfmRystEo6ObI80RKBzxKUnhsGowDqV2YCUXxxTD9Gkt7TyFLZGe5iZF5GLe6ZZO wgDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=RSgUj4PX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b21si8025017ejz.183.2020.10.26.03.17.56; Mon, 26 Oct 2020 03:18:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=RSgUj4PX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422415AbgJZJeP (ORCPT + 99 others); Mon, 26 Oct 2020 05:34:15 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:34949 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422416AbgJZJeM (ORCPT ); Mon, 26 Oct 2020 05:34:12 -0400 Received: by mail-wr1-f66.google.com with SMTP id n15so11604367wrq.2 for ; Mon, 26 Oct 2020 02:34:08 -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=gYzieEkyuY5GK4uIKGUgpkX8O/MjJBNKsXAywCS/qUs=; b=RSgUj4PXQdjvjhUxcBC2NkgGKsRMLzp3PYY9p4Uj7B7AfgPG3ewdfVQ2Mxj+FvMlKu 0nM+RnXg+PoAL+CHWjAhOGn0dcjtQLB4B33Ee9ctifIVcnGBeey4DCtSyvZ/0tKbQpNJ IBJhSVHrSrVQvlRbv8fS4LsmShIvyYlV2SRTk= 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=gYzieEkyuY5GK4uIKGUgpkX8O/MjJBNKsXAywCS/qUs=; b=kRb+ENNlaxele4gQN2rl4ueO1IsJo8Bc9O0uNXee8SRCmcR2J+7S7eKykkh6rCbozK HYT8kbQhdb/mgVOsb2zCqd/jLKsHnrQzFgOwO08L5v+zges45zc4CZIIctVvewEgtu/b U1sZETOf36nzw00w3lTMkIbZSZ7tEIGMtwHySewKh9aF1VHWlkUtgVrbhKtn6X7CSoSC dkxyTEa0fmCvuSPODIAL8SmLx/wwpXt/WZ4zen7WjYPk0oG7oseOykWFyuokgcCpb9Ie vu7UpnzEmEquWd8s/hfHOWLO2bvi6/1y02vi82OCM29S5vb5ct5VbPeZyP8/3y+3YeF4 a7TQ== X-Gm-Message-State: AOAM530IY+zewahs+5hpQjqvDTjGAHyvzjLirJvXQbX1B9eLW8Z9jbUw bc4bmfBGCSdWvyKUs56RCCUWGg== X-Received: by 2002:adf:a306:: with SMTP id c6mr16496122wrb.160.1603704848072; Mon, 26 Oct 2020 02:34:08 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id j5sm23591677wrx.88.2020.10.26.02.34.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 02:34:07 -0700 (PDT) Date: Mon, 26 Oct 2020 10:34:05 +0100 From: Daniel Vetter To: Rob Clark Cc: Lucas Stach , Rob Clark , freedreno , David Airlie , linux-arm-msm , open list , dri-devel , "Kristian H . Kristensen" , Sean Paul Subject: Re: [PATCH v4 23/23] drm/msm: Don't implicit-sync if only a single ring Message-ID: <20201026093405.GG401619@phenom.ffwll.local> Mail-Followup-To: Rob Clark , Lucas Stach , Rob Clark , freedreno , David Airlie , linux-arm-msm , open list , dri-devel , "Kristian H . Kristensen" , Sean Paul References: <20201023165136.561680-1-robdclark@gmail.com> <20201023165136.561680-24-robdclark@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 23, 2020 at 08:49:14PM -0700, Rob Clark wrote: > On Fri, Oct 23, 2020 at 11:20 AM Lucas Stach wrote: > > > > On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > 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)? > > we already do this.. as was discussed on an earlier iteration of this patchset > > But I'm not aware of any other non-gpu related implicit sync use-case > (even on imx devices where display is decoupled from gpu).. I'll > revert the patch if someone comes up with one, but otherwise lets let > the implicit sync baggage die The thing is, dma_resv won't die, even if implicit sync is dead. We're using internally for activity tracking and memory management. If you don't set these, then we can't share generic code with msm, and I think everyone inventing their own memory management is a bit a mistake. Now you only kill the implicit write sync stuff here, but I'm not sure that's worth much since you still install all the read fences for consistency. And if userspace doesn't want to be synced, they can set the flag and do this on their own: I think you should be able to achieve exactly the same thing in mesa. Aside: If you're worried about overhead, you can do O(1) submit if you manage your ppgtt like amdgpu does. -Daniel > > BR, > -R > > > > > > > Regards, > > Lucas > > > > > Signed-off-by: Rob Clark > > > Reviewed-by: Kristian H. Kristensen > > > --- > > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch