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=-8.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, 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 8F80BC4707A for ; Fri, 21 May 2021 15:16: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 0A71E601FD for ; Fri, 21 May 2021 15:16:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A71E601FD 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 8B0E06EC4D; Fri, 21 May 2021 15:16:32 +0000 (UTC) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by gabe.freedesktop.org (Postfix) with ESMTPS id C3D176EC4D for ; Fri, 21 May 2021 15:16:30 +0000 (UTC) Received: by mail-wm1-x329.google.com with SMTP id z137-20020a1c7e8f0000b02901774f2a7dc4so6979009wmc.0 for ; Fri, 21 May 2021 08:16:30 -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:references:mime-version :content-disposition:in-reply-to; bh=1Q2Ew9yc46WJuKj39NJVAEfvl4U967Nhg8KVFP+/TzY=; b=M4rfqYr5PqI/F1ZgVW/kusxcWLhR6aAPBbHEDGFPUnQWuqGZz22lq7AZMqgspb8PU0 yh9G0qhDABo2tv4VABcZMBUP7brzz8wXIjz2SVF0oW3MOJIGZRLzSUSEH4NEdbRYJIGw z81dr7IwpJATnYPEyI9CxDx7UfiElLse6CXag= 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:references :mime-version:content-disposition:in-reply-to; bh=1Q2Ew9yc46WJuKj39NJVAEfvl4U967Nhg8KVFP+/TzY=; b=Jmj/1aByk6KbjsHOPUYD8dT35h50BXfK8HRg+viF7MV1KY1Xxn26ykfYTAVfS2uBCi R1k9uom3FfzEKI09W4ngXFfQkufUfk/MbQiezb2RYciaIdHNrVPzmZs6k1Yq4d9La7h8 oAiYx1CO6UMC/9UcfqJncfFDuqdbvsEHnClLfg2eV5GHSbORWegnb0mCtBvxYmBzQj0C M066fwI7QEVWs5eVFfs/KF1Zbsy2b4dX1c7LpvzQfwfvZTppx2MstmVQSE1UV32NHFXk +eb7W3fitQcl7qQm0kXOjd5y3FpmDB9oXxGDDMEAIFhX2WAMzZYTvSKdW001TY+sl1dw 9wbg== X-Gm-Message-State: AOAM533e6jv9szvv8QVAvT72WiDnpk7VOzFJQ3pQ+d6PHlsPLgPwFKqI Owj1SIvdaKbSBBi7dh7exfThEQ== X-Google-Smtp-Source: ABdhPJxrjpIuptRXcKR15BnNkXK4XByaclZwmXR1GWTObteW974iWeRYDnAC3q6ddoQBgsnzXDJJKg== X-Received: by 2002:a7b:cd0e:: with SMTP id f14mr9747466wmj.22.1621610189492; Fri, 21 May 2021 08:16:29 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id v12sm2367730wru.73.2021.05.21.08.16.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 May 2021 08:16:28 -0700 (PDT) Date: Fri, 21 May 2021 17:16:26 +0200 From: Daniel Vetter To: Bas Nieuwenhuizen Subject: Re: [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules Message-ID: References: <20210521090959.1663703-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.10.32scarlett+ 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 , Daniel Stone , Christian =?iso-8859-1?Q?K=F6nig?= , Daniel Vetter , Intel Graphics Development , Kevin Wang , DRI Development , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Luben Tuikov , "Kristian H . Kristensen" , Chen Li , Daniel Vetter , Alex Deucher , mesa-dev , Michel =?iso-8859-1?Q?D=E4nzer?= , Dennis Li , Deepak R Varma Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote: > On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote: > > > > On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote: > > > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > > > > --- > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > > index 88a24a0b5691..cc8426e1e8a8 100644 > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p, > > > > amdgpu_bo_list_for_each_entry(e, p->bo_list) { > > > > struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo); > > > > > > > > - /* Make sure we use the exclusive slot for shared BOs */ > > > > - if (bo->prime_shared_count) > > > > + /* Make sure we use the exclusive slot for all potentially shared BOs */ > > > > + if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)) > > > > e->tv.num_shared = 0; > > > > > > I think it also makes sense to skip this with > > > AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think > > > anyone expects implicit sync to happen with those. > > > > Ah yes, I missed this entirely. So the "no implicit flag" is already > > there, and the _only_ thing that's missing really is a way to fish out the > > implicit fences, and set them. > > > > https://lore.kernel.org/dri-devel/20210520190007.534046-1-jason@jlekstrand.net/ > > > > So I think all that's really needed in radv is not setting > > RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl > > are present (means you need to do some import/export and keep the fd > > around for winsys buffers, but shouldn't be too bad), and then control the > > implicit fences entirely explicitly like vk expects. > > That is the part I'm less sure about. This is a BO wide flag so we are > also disabling implicit sync in the compositor. If the compositor does > only do read stuff that is ok, as the inserted exclusive fence will > work for that. But as I learned recently the app provided buffer may > end up being written to by the X server which open a whole can of > potential problems if implicit sync gets disabled between Xserver > operations on the app provided buffer. Hence setting that on the WSI > buffer is a whole new can of potential problems and hence I've said a > submission based flag would be preferred. > > I can certainly try it out though. Hm yeah that's the wrong flag. We need a flag on the drm_file which the explicit userspace sets. And which is valid only for itself. There's a nice flags field when creating a ctx, but it's not validated and there's already a comment that we have to filter out garbage priority, so that's not use. I'll whip up something entirely untested just as a draft. -Daniel > > > > > Are you bored enough to type this up for radv? I'll give Jason's kernel > > stuff another review meanwhile. > > -Daniel > > > > > > e->bo_va = amdgpu_vm_bo_find(vm, bo); > > > > } > > > > -- > > > > 2.31.0 > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch