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 6579DC47078 for ; Fri, 21 May 2021 15:00:53 +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 2E63461244 for ; Fri, 21 May 2021 15:00:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E63461244 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=basnieuwenhuizen.nl 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 630A96EB16; Fri, 21 May 2021 15:00:47 +0000 (UTC) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) by gabe.freedesktop.org (Postfix) with ESMTPS id 058586E881 for ; Fri, 21 May 2021 15:00:46 +0000 (UTC) Received: by mail-il1-x132.google.com with SMTP id m1so16763341ilg.10 for ; Fri, 21 May 2021 08:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basnieuwenhuizen.nl; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oQj0FNiG5bAM6343Ct0j671goIZefi3SHzLA0KT/hl8=; b=WRZG8R/TiBJaa40Inm1tkYallr21e2Cs/WDV6SMojo2Kx+RJPr6/Y8bBCZuWNFWr9P HOScqfCSYVrJMAVgScEYpvYHplI7iVuU9MkADe30miNNuV4+V/X7FN5lhdilznpCtJjg DD8CyaqrLA5qhtxxlI9sS+Ww8R/oNhO79fGag+B6OpA4SqWvZv8sLBIBfx5Em1FaccbW WHhzocOycwZNsbN/6KZcG9KUmTQu42swG1xmXQAcFJ/atgF+f34Y2cUXSwgTwCSbkg/x Lqple5/CpftCT7yChrBKBh2HhYqAl/z98MB3iPrliv0cdlTnBLj4vmM9dDGRj8k+UTe2 gljw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oQj0FNiG5bAM6343Ct0j671goIZefi3SHzLA0KT/hl8=; b=UYtAwzn1l1FTFVeRk1H8aTHr63hrPLz+7gv6UWzIi/ISGTiTqUciIRD6XLX369htv5 J9PAQ4eWQhFh0lVE2GNOjse4RfcbvBkw0UFbdFuGY5Tm5pjY45WxNG1PY9i6ss6pjF8k dyjH53TBo9CWvs0hgsiUyCdtJswMcsnhKXiQyMm7qMUHd+BWHyoY3sHSx9qnBX9vR+n+ 4rLQLHdPu6aCYSI0WwbGoq2jnPceiUw//5GPtndceYcCRCBCz3Hp9I1uTXsmzTxgZ0Jk 3pYdSJwTIoxX92pw5F7uUmNEY6by+mez2fH0TwwmSdmaspCtGvUSJqBDKgSM0YtGPLF9 FAVQ== X-Gm-Message-State: AOAM532LD1l6RWEN5+IVCjMZLYC3Zxacj6DGVYstEUl6bandpWuAVypH efYIYFmx5eggRAIeytNKJOJ+m82exKZcGreMuC7Cuw== X-Google-Smtp-Source: ABdhPJwFLlg9azhy3Koju3Q+BJeqcaD6/u45aY3WiO+f1FPZOGvKThJnsIadcwaVPRhwU3mmQmZX8X01e+eLbQeJu0k= X-Received: by 2002:a05:6e02:11b3:: with SMTP id 19mr11897277ilj.41.1621609245262; Fri, 21 May 2021 08:00:45 -0700 (PDT) MIME-Version: 1.0 References: <20210521090959.1663703-1-daniel.vetter@ffwll.ch> In-Reply-To: From: Bas Nieuwenhuizen Date: Fri, 21 May 2021 17:00:46 +0200 Message-ID: Subject: Re: [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules To: Daniel Vetter Content-Type: text/plain; charset="UTF-8" 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 , =?UTF-8?Q?Christian_K=C3=B6nig?= , 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 , =?UTF-8?Q?Michel_D=C3=A4nzer?= , Dennis Li , Deepak R Varma Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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. > > 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