Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200225235856.975366-1-jason@jlekstrand.net> <8066d8b2-dd6a-10ef-a7bb-2c18a0661912@amd.com>
 <20200226100523.GQ2363188@phenom.ffwll.local> <CAOFGe94O66HL212aXqhi9tdYqw---Xm-fwNSV4pxHyPmpSGpbg@mail.gmail.com>
 <CAP+8YyEUz29fXDW5kO_0ZG6c849=TuFWCK8ynT3LuM+Tn+rMzw@mail.gmail.com>
 <810a26e7-4294-a615-b7ee-18148ac70641@amd.com> <CAOFGe96namyeQXTvdrduM+=wkJuoWWx34CxcsJHS3fcCaKDadw@mail.gmail.com>
 <21aeacc0-f3ae-c5dd-66df-4d2f3d73f73e@amd.com> <CAOFGe95Gx=kX=sxwhx1FYmXQuPtGAKwt2V5YodQBwJXujE3WwA@mail.gmail.com>
 <CAOFGe97XSxgzCViOH=2+B2_d5P3vGifKmvAw-JrzRQbbRMRbcg@mail.gmail.com>
 <6fb8becf-9e6b-f59e-9c22-2b20069241a7@amd.com> <CAOFGe94gv9N+6n6oEC2aRtsmy7kBfx1D_R6WLQSGq7-8yUM_OQ@mail.gmail.com>
 <203505dc-7b75-1135-587e-cc6e88ade8cd@amd.com>
In-Reply-To: <203505dc-7b75-1135-587e-cc6e88ade8cd@amd.com>
From:   Jason Ekstrand <jason@jlekstrand.net>
Date:   Tue, 10 Mar 2020 22:43:22 -0500
Message-ID: <CAOFGe94DnZcTb51TE3kFYxMgLkEWdNg2Yz3f4BEWNXz4GTOs7Q@mail.gmail.com>
Subject: Re: [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files
To:     =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>
Cc:     Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>,
        Dave Airlie <airlied@redhat.com>,
        Jesse Hall <jessehall@google.com>,
        James Jones <jajones@nvidia.com>,
        Daniel Stone <daniels@collabora.com>,
        =?UTF-8?Q?Kristian_H=C3=B8gsberg?= <hoegsberg@google.com>,
        Sumit Semwal <sumit.semwal@linaro.org>,
        Chenbo Feng <fengc@google.com>,
        Greg Hackmann <ghackmann@google.com>,
        linux-media@vger.kernel.org,
        Maling list - DRI developers 
        <dri-devel@lists.freedesktop.org>, linaro-mm-sig@lists.linaro.org,
        LKML <linux-kernel@vger.kernel.org>,
        Daniel Vetter <daniel.vetter@ffwll.ch>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 9, 2020 at 11:21 AM Christian K=C3=B6nig
<christian.koenig@amd.com> wrote:
>
> Am 05.03.20 um 16:54 schrieb Jason Ekstrand:
> > On Thu, Mar 5, 2020 at 7:06 AM Christian K=C3=B6nig <christian.koenig@a=
md.com> wrote:
> >> [SNIP]
> >> Well as far as I can see this won't work because it would break the
> >> semantics of the timeline sync.
> > I'm not 100% convinced it has to.  We already have support for the
> > seqno regressing and we ensure that we still wait for all the fences.
> > I thought maybe we could use that but I haven't spent enough time
> > looking at the details to be sure.  I may be missing something.
>
> That won't work. The seqno regression works by punishing userspace for
> doing something stupid and undefined.
>
> Be we can't do that under normal circumstances.
>
> >> I can prototype that if you want, shouldn't be more than a few hours o=
f
> >> hacking anyway.
> > If you'd like to, go for it.  I'd be happy to give it a go as well but
> > if you already know what you want, it may be easier for you to just
> > write the patch for the cursor.
>
> Send you two patches for that a few minutes ago. But keep in mind that
> those are completely untested.

No worries.  They were full of bugs but I think I've got them sorted
out now.  The v2's I'm about to send seem to work.  I'm going to leave
a Vulkan demo running all night long just to make sure I'm not leaking
memory like mad.

--Jason

> > Two more questions:
> >
> >   1. Do you want this collapsing to happen every time we create a
> > dma_fence_array or should it be a special entrypoint?  Collapsing all
> > the time likely means doing extra array calculations instead of the
> > dma_fence_array taking ownership of the array that's passed in.  My
> > gut says that cost is ok; but my gut doesn't spend much time in kernel
> > space.
>
> In my prototype implementation that is a dma_resv function you call and
> get either a single fence or a dma_fence_array with the collapsed fences
> in return.
>
> But I wouldn't add that to the general dma_fence_array_init function
> since this is still a rather special case. Well see the patches, they
> should be pretty self explaining.
>
> >   2. When we do the collapsing, should we call dma_fence_is_signaled()
> > to avoid adding signaled fences to the array?  It seems like avoiding
> > adding references to fences that are already signaled would let the
> > kernel clean them up faster and reduce the likelihood that a fence
> > will hang around forever because it keeps getting added to arrays with
> > other unsignaled fences.
>
> I think so. Can't think of a good reason why we would want to add
> already signaled fences to the array.
>
> Christian.
>
> >
> > --Jason
>