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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 4D3D9C4708A for ; Thu, 27 May 2021 10:33:57 +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 0B7336135C for ; Thu, 27 May 2021 10:33:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B7336135C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A17486EE65; Thu, 27 May 2021 10:33:56 +0000 (UTC) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by gabe.freedesktop.org (Postfix) with ESMTPS id D4A8C6EE65 for ; Thu, 27 May 2021 10:33:55 +0000 (UTC) Received: by mail-wr1-x435.google.com with SMTP id m18so4237417wrv.2 for ; Thu, 27 May 2021 03:33:55 -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:content-transfer-encoding:in-reply-to; bh=eUx4Ww94ghT1OFJYFV4k9kBh2hCOi+Z+Yz3tYP5DhzI=; b=AFJ00knjSZZRyeNi0sR41ZdQpTt1HZ4n5swMbRpwTy4JehjZ+iQ3b9O9JeFWhuTXDH +Q04s3vxSKD3LCRICT7h00PydUT7UAML3x/I6wU+t1w6WWBS+zp+dBzzYsWphLwfIbK3 2na3QgUZuk0TlpL3slXn28V6TA4ZIgEXREhqo= 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:content-transfer-encoding :in-reply-to; bh=eUx4Ww94ghT1OFJYFV4k9kBh2hCOi+Z+Yz3tYP5DhzI=; b=XSVseAzRNFf8qtC8uMyYhx6koI5lyIeA1I03qbIhje6Ryn/+8Kqjz8v/iwXf5lt2me E1hnuPRTBQhOmMi1GgRL9ZTE0EP/N+0bGj+/Yjw7RiKDIffBENEc6ud+RdGTTnkCiu/e 0sVUkNr4nJE8SN+inOKlSYwzfBGPtgZsqQRebkBt9s+1VcfTREM21wIJyDXYvE4E81xi 4n0xmnJsaQejF25o69Fkrh9H7mKJCAfKpqkDiJ4ji2n+CKxyNksb+LJycrSv9oRer28n K6jl+DdJ+O/cSCgiG4Tx2E9/Z/H5gN8/WyiYoxSIFng5t5L2KjGgcCnJz0Gg2QlKwjLt swIQ== X-Gm-Message-State: AOAM532HZBPf0g2K+jjwPi5IqLbjVYsvWNYNKgYWu5RVaxBaDKk4rNbj pjYJ9NNgeEFe0HeNZgUvNw2Mrg== X-Google-Smtp-Source: ABdhPJznwqtO3kpYhHjv+rwBJ46VyzmMAk9vedbccVxp4EAUNtvI1Dz5Xu5QJO82xXHa4GKwCTtSdA== X-Received: by 2002:a05:6000:c2:: with SMTP id q2mr2637793wrx.288.1622111634527; Thu, 27 May 2021 03:33:54 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id b135sm1234200wmb.5.2021.05.27.03.33.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 May 2021 03:33:54 -0700 (PDT) Date: Thu, 27 May 2021 12:33:52 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Message-ID: References: <20210525211753.1086069-1-jason@jlekstrand.net> <20210525211753.1086069-6-jason@jlekstrand.net> <770eb698-1dde-9e46-da83-44911d96abec@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.10.32scarlett+ Subject: Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11) X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Simon Ser , intel-gfx , dri-devel , Daniel Vetter , Sumit Semwal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, May 26, 2021 at 03:23:01PM +0200, Christian K=F6nig wrote: > = > = > Am 26.05.21 um 15:12 schrieb Daniel Stone: > > Hi, > > = > > On Wed, 26 May 2021 at 13:46, Christian K=F6nig wrote: > > > Am 26.05.21 um 13:31 schrieb Daniel Stone: > > > > How would we insert a syncobj+val into a resv though? Like, if we p= ass > > > > an unmaterialised syncobj+val here to insert into the resv, then an > > > > implicit-only media user (or KMS) goes to sync against the resv, wh= at > > > > happens? > > > Well this is for exporting, not importing. So we don't need to worry > > > about that. > > > = > > > It's just my thinking because the drm_syncobj is the backing object on > > > VkSemaphore implementations these days, isn't it? > > Yeah, I can see that to an extent. But then binary vs. timeline > > syncobjs are very different in use (which is unfortunate tbh), and > > then we have an asymmetry between syncobj export & sync_file import. > > = > > You're right that we do want a syncobj though. This is probably not > > practical due to smashing uAPI to bits, but if we could wind the clock > > back a couple of years, I suspect the interface we want is that export > > can either export a sync_file or a binary syncobj, and further that > > binary syncobjs could transparently act as timeline semaphores by > > mapping any value (either wait or signal) to the binary signal. In > > hindsight, we should probably just never have had binary syncobj. Oh > > well. > = > Well the later is the case IIRC. Don't ask me for the detail semantics, b= ut > in general the drm_syncobj in timeline mode is compatible to the binary > mode. > = > The sync_file is also import/exportable to a certain drm_syncobj timeline > point (or as binary signal). So no big deal, we are all compatible here :) > = > I just thought that it might be more appropriate to return a drm_syncobj > directly instead of a sync_file. I think another big potential user for this is a vk-based compositor which needs to interact/support implicit synced clients. And compositor world I think is right now still more sync_file (because that's where we started with atomic kms ioctl). The other slight nudge is that drm_syncobj is a drm thing, so we'd first need to lift it out into drivers/dma-buf (and hand-wave the DRM prefix away) for it to be a non-awkward fit for dma-buf. Plus you can convert them to the other form anyway, so really doesn't matter much. But for the above reasons I'm leaning slightly towards sync_file. Except if compositor folks tell me I'm a fool and why :-) -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 ABA84C4707F for ; Thu, 27 May 2021 10:33:58 +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 72C27610CB for ; Thu, 27 May 2021 10:33:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72C27610CB 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 666B46EE68; Thu, 27 May 2021 10:33:57 +0000 (UTC) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by gabe.freedesktop.org (Postfix) with ESMTPS id D561C6EE66 for ; Thu, 27 May 2021 10:33:55 +0000 (UTC) Received: by mail-wr1-x435.google.com with SMTP id j14so4208201wrq.5 for ; Thu, 27 May 2021 03:33:55 -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:content-transfer-encoding:in-reply-to; bh=eUx4Ww94ghT1OFJYFV4k9kBh2hCOi+Z+Yz3tYP5DhzI=; b=AFJ00knjSZZRyeNi0sR41ZdQpTt1HZ4n5swMbRpwTy4JehjZ+iQ3b9O9JeFWhuTXDH +Q04s3vxSKD3LCRICT7h00PydUT7UAML3x/I6wU+t1w6WWBS+zp+dBzzYsWphLwfIbK3 2na3QgUZuk0TlpL3slXn28V6TA4ZIgEXREhqo= 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:content-transfer-encoding :in-reply-to; bh=eUx4Ww94ghT1OFJYFV4k9kBh2hCOi+Z+Yz3tYP5DhzI=; b=ruySFFeIE+LwzHRhzWBLbiBAmWa45X1SwznYpb8gpJEKbEVSJRChVidPKBd98dBu+5 x3bEdCTA1M9WYoevxhC5bxG/80dIls3Arzcd1j4T/mAOaiMJRQWytka5y+4vOZHTa+V9 DNPf6BVBfPJsffmgrwxcJE65XIJ9mxI2Bgy3/FHhpAWo2K1TBMEffhV7Js1j8nAzp6CH WksGyxv69CfOSd9wTuXExXK5AC6aTaQCbScKeJNWpcm3tiHkzzq4kKE8U9VFNM64//23 xrWH82A3qyceAwWT/A3unejWPkA59qm7IjXjjARNCY6/LfwowLeMg/e5nxwr2578oMFY AMOw== X-Gm-Message-State: AOAM531BJoR5f91W3Xvh/Y8F6nhPkK8hepf2tJRCoXgDxKRdDbiDMUSI lfN4mtLaAoyE91te3/C4/KlBAg== X-Google-Smtp-Source: ABdhPJznwqtO3kpYhHjv+rwBJ46VyzmMAk9vedbccVxp4EAUNtvI1Dz5Xu5QJO82xXHa4GKwCTtSdA== X-Received: by 2002:a05:6000:c2:: with SMTP id q2mr2637793wrx.288.1622111634527; Thu, 27 May 2021 03:33:54 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id b135sm1234200wmb.5.2021.05.27.03.33.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 May 2021 03:33:54 -0700 (PDT) Date: Thu, 27 May 2021 12:33:52 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11) Message-ID: References: <20210525211753.1086069-1-jason@jlekstrand.net> <20210525211753.1086069-6-jason@jlekstrand.net> <770eb698-1dde-9e46-da83-44911d96abec@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: intel-gfx , dri-devel , Jason Ekstrand , Daniel Vetter Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, May 26, 2021 at 03:23:01PM +0200, Christian König wrote: > > > Am 26.05.21 um 15:12 schrieb Daniel Stone: > > Hi, > > > > On Wed, 26 May 2021 at 13:46, Christian König wrote: > > > Am 26.05.21 um 13:31 schrieb Daniel Stone: > > > > How would we insert a syncobj+val into a resv though? Like, if we pass > > > > an unmaterialised syncobj+val here to insert into the resv, then an > > > > implicit-only media user (or KMS) goes to sync against the resv, what > > > > happens? > > > Well this is for exporting, not importing. So we don't need to worry > > > about that. > > > > > > It's just my thinking because the drm_syncobj is the backing object on > > > VkSemaphore implementations these days, isn't it? > > Yeah, I can see that to an extent. But then binary vs. timeline > > syncobjs are very different in use (which is unfortunate tbh), and > > then we have an asymmetry between syncobj export & sync_file import. > > > > You're right that we do want a syncobj though. This is probably not > > practical due to smashing uAPI to bits, but if we could wind the clock > > back a couple of years, I suspect the interface we want is that export > > can either export a sync_file or a binary syncobj, and further that > > binary syncobjs could transparently act as timeline semaphores by > > mapping any value (either wait or signal) to the binary signal. In > > hindsight, we should probably just never have had binary syncobj. Oh > > well. > > Well the later is the case IIRC. Don't ask me for the detail semantics, but > in general the drm_syncobj in timeline mode is compatible to the binary > mode. > > The sync_file is also import/exportable to a certain drm_syncobj timeline > point (or as binary signal). So no big deal, we are all compatible here :) > > I just thought that it might be more appropriate to return a drm_syncobj > directly instead of a sync_file. I think another big potential user for this is a vk-based compositor which needs to interact/support implicit synced clients. And compositor world I think is right now still more sync_file (because that's where we started with atomic kms ioctl). The other slight nudge is that drm_syncobj is a drm thing, so we'd first need to lift it out into drivers/dma-buf (and hand-wave the DRM prefix away) for it to be a non-awkward fit for dma-buf. Plus you can convert them to the other form anyway, so really doesn't matter much. But for the above reasons I'm leaning slightly towards sync_file. Except if compositor folks tell me I'm a fool and why :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch