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 8D945C47089 for ; Thu, 27 May 2021 15:39:23 +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 32078613B4 for ; Thu, 27 May 2021 15:39:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32078613B4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jlekstrand.net 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 ACEAE6E046; Thu, 27 May 2021 15:39:22 +0000 (UTC) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by gabe.freedesktop.org (Postfix) with ESMTPS id 035E26E073 for ; Thu, 27 May 2021 15:39:21 +0000 (UTC) Received: by mail-yb1-xb2b.google.com with SMTP id f9so1271323ybo.6 for ; Thu, 27 May 2021 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jlekstrand-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=0AJfGN9E24XOsXAh7WyvJAru8MAlsyAmbHYQ6ndEqGE=; b=n0F8zlpJx+uKh8o5Eb40GCmDKjYOcoc9/SENacxnC/hS7av8ZDuIP9s55YZ52hbKSX Ua4VyGj+eRrwUi9A0upW/MPR3aLyqYEJY1HE7kdLXY+voTKyQApuNOzyPxTB25cyS9ax HnVmFCK4cam/1mn/yEQ4O5I0WHFkzNjrfjijrTz4tHhMKws3PrgRdQd8XuB6mKMoCNt/ HAr4GWpch/GCBG4d+3RaVHYAasUq8TPp3Y5VN646bDjxyzpsOkz7VJyijpIfcI1o/2M0 N89koBjF/8LRSv3bN9PLjPhM8ihHR1mbvpIBL9eJT72DyiDFU43DQmcfvd614QQVJ+H4 eMAw== 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:content-transfer-encoding; bh=0AJfGN9E24XOsXAh7WyvJAru8MAlsyAmbHYQ6ndEqGE=; b=Ea+o7iJPgLxPlPSqRxX4MK7Y+l5lD80waJ+tsn+mYo3U3GpzkNvajn5UIF+ztNE0cL razKD9Uo/1A2DtqPvNFFhjWy1nS42P1wSmdk4meeSCJmcuO7PZUIfx3nsnbKAUBBEtN8 1loUubP1K+6TxD0S2LITo7xEYdhDEWjfdTYzV8HJmZStUlq7R9vuHHvFktgFZXVMlpR1 EFH4KQcniS6svkxWVt0+HAX/vv/NByt83IZO6LvhNnQd4Hbit5A2Yf9+yejX6rkw91jX Vcv+KKtGsI1BSnET7aYzn3mhzQlbVxC0vIIdjxrjwiHSo/nHcxdZfSDkXnXqm1NgX4x2 fgmA== X-Gm-Message-State: AOAM531KTi/JSgY6QOl3P/whG2eAp+CG2n22yaU3Xs3fGDnzSahu+0kG HJzHFx/5WiABpbDDmpQEFoW1m7QLif4wbHkKgs1aajEkVI8= X-Google-Smtp-Source: ABdhPJzqyepqasUorYM2LiZLA/CiqbdyPtZhS/6eEiDfwPJ6j4Mth3MU7LV/HlJqdQrbg4ptJQcVI1Ko+TLYRQ9kBvo= X-Received: by 2002:a05:6902:705:: with SMTP id k5mr5504628ybt.241.1622129960996; Thu, 27 May 2021 08:39:20 -0700 (PDT) MIME-Version: 1.0 References: <20210525211753.1086069-1-jason@jlekstrand.net> <20210525211753.1086069-6-jason@jlekstrand.net> <770eb698-1dde-9e46-da83-44911d96abec@amd.com> In-Reply-To: From: Jason Ekstrand Date: Thu, 27 May 2021 10:39:09 -0500 Message-ID: To: =?UTF-8?Q?Christian_K=C3=B6nig?= , Maling list - DRI developers , Simon Ser , Daniel Vetter , Sumit Semwal , Intel GFX , Daniel Stone 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" T24gVGh1LCBNYXkgMjcsIDIwMjEgYXQgNDo0OSBBTSBDaHJpc3RpYW4gS8O2bmlnCjxjaHJpc3Rp YW4ua29lbmlnQGFtZC5jb20+IHdyb3RlOgo+Cj4gQW0gMjYuMDUuMjEgdW0gMTk6NDIgc2Nocmll YiBKYXNvbiBFa3N0cmFuZDoKPiA+IE9uIFdlZCwgTWF5IDI2LCAyMDIxIGF0IDY6MDIgQU0gQ2hy aXN0aWFuIEvDtm5pZwo+ID4gPGNocmlzdGlhbi5rb2VuaWdAYW1kLmNvbT4gd3JvdGU6Cj4gPj4g UmVnYXJkaW5nIHRoYXQsIHdoeSBkbyB3ZSBhY3R1YWxseSB1c2UgYSBzeW5jZmlsZSBhbmQgbm90 IGEgZHJtX3N5bmNvYmoKPiA+PiBoZXJlPwo+ID4gQSBzeW5jIGZpbGUgaXMgYSB1c2Vyc3BhY2Ug aGFuZGxlIHRvIGEgZG1hX2ZlbmNlIHdoaWNoIGlzIGV4YWN0bHkgd2hhdAo+ID4gd2UncmUgZ3Jh YmJpbmcgZnJvbSB0aGUgZG1hLWJ1ZiBzbyBpdCdzIGEgYmV0dGVyIG1hdGNoLiAgQSBzeW5jb2Jq LCBvbgo+ID4gdGhlIG90aGVyIGhhbmQsIGlzIGEgY29udGFpbmVyIGZvciBmZW5jZXMuICBJZiB3 ZSByZWFsbHkgd2FudCBpdCBpbiBhCj4gPiBzeW5jb2JqICh3aGljaCB3ZSBtYXkpLCB3ZSBjYW4g dXNlIGFub3RoZXIgaW9jdGwgdG8gc3R1ZmYgaXQgaW4gdGhlcmUuCj4gPiBUaGUgb25seSB0aGlu ZyBtYWtpbmcgdGhpcyB3b3JrIGluIHRlcm1zIG9mIHN5bmNvYmogd291bGQgc2F2ZSB1cyBpcyBh Cj4gPiBsaXR0bGUgaW9jdGwgb3ZlcmhlYWQuICBJbiBteSBNZXNhIHBhdGNoZXMsIHdlIGRvIHN0 dWZmIGl0IGluIGEKPiA+IHN5bmNvYmogYnV0LCBpbnN0ZWFkIG9mIGFjdGluZyBvbiB0aGUgc3lu Y29iaiBkaXJlY3RseSwgd2UgZ28gdGhyb3VnaAo+ID4gdmtTZW1hcGhvcmVJbXBvcnRGZCgpIHdo aWNoIGlzIHdheSBtb3JlIGNvbnZlbmllbnQgZm9yIGdlbmVyaWMgV1NJCj4gPiBjb2RlLgo+Cj4g WWVhaCwgdGhhdCBpcyBhIHJlYWxseSBnb29kIGFyZ3VtZW50Lgo+Cj4gPiBJdCBhbHNvIHdvcmtz IG5pY2VyIGJlY2F1c2UgYSBzeW5jX2ZpbGUgaXMgYSBwcmV0dHkgZ2VuZXJpYyBjb25zdHJ1Y3QK PiA+IGJ1dCBhIHN5bmNvYmogaXMgYSBEUk0gY29uc3RydWN0LiAgVGhpcyBsZXRzIHVzIGRvIHRo ZSBleHBvcnQgaW4gYW4KPiA+IGVudGlyZWx5IGRyaXZlci1nZW5lcmljIHdheSB3aXRob3V0IGV2 ZW4gaGF2aW5nIGFjY2VzcyB0byBhIERSTSBmZC4KPiA+IEl0IGFsbCBoYXBwZW5zIGFzIGFuIGlv Y3RsIG9uIHRoZSBkbWEtYnVmLgo+Cj4gV2VsbCB0aGF0J3MgYW4gZXZlbiBiZXR0ZXIgYXJndW1l bnQgYW5kIEkgdGhpbmsgdGhlIGtpbGxlciBhcmd1bWVudCBoZXJlLgoKQ29vbC4KCj4gV2Ugc2hv dWxkIHByb2JhYmx5IG1lbnRpb24gdGhhdCBvbiB0aGUgY29tbWl0IG1lc3NhZ2UgYXMgYSBzaW5n bGUKPiBzZW50ZW5jZSBzb21ld2hlcmUuCgpIYXBweSB0byBkbyBzby4gIEhvdyBkb2VzIHRoaXMg c291bmQ6CgpCeSBtYWtpbmcgdGhpcyBhbiBpb2N0bCBvbiB0aGUgZG1hLWJ1ZiBpdHNlbGYsIGl0 IGFsbG93cyB0aGlzIG5ldwpmdW5jdGlvbmFsaXR5IHRvIGJlIHVzZWQgaW4gYW4gZW50aXJlbHkg ZHJpdmVyLWFnbm9zdGljIHdheSB3aXRob3V0CmhhdmluZyBhY2Nlc3MgdG8gYSBEUk0gZmQuIFRo aXMgbWFrZXMgaXQgaWRlYWwgZm9yIHVzZSBpbgpkcml2ZXItZ2VuZXJpYyBjb2RlIGluIE1lc2Eg b3IgaW4gYSBjbGllbnQgc3VjaCBhcyBhIGNvbXBvc2l0b3Igd2hlcmUKdGhlIERSTSBmZCBtYXkg YmUgaGFyZCB0byByZWFjaC4KCj4gQlRXOiBZb3UgcmVwbGllZCBleGNsdXNpdmVseSB0byBtZS4g V2FzIHRoYXQgaW50ZW50aW9uYWxseT8gSSBkb24ndAo+IHRoaW5rIHNvIDopCgpPb3BzLi4uICBJ J3ZlIHJlLWFkZGVkIHRoZSB3aG9sZSBsb3QgaW4gdGhpcyByZXBseS4KCi0tSmFzb24KCj4gUmVn YXJkcywKPiBDaHJpc3RpYW4uCj4KPiA+Cj4gPiBPbiBXZWQsIE1heSAyNiwgMjAyMSBhdCA4OjIz IEFNIENocmlzdGlhbiBLw7ZuaWcKPiA+IDxjaHJpc3RpYW4ua29lbmlnQGFtZC5jb20+IHdyb3Rl Ogo+ID4KPiA+PiBBbSAyNi4wNS4yMSB1bSAxNToxMiBzY2hyaWViIERhbmllbCBTdG9uZToKPiA+ Pj4gT24gV2VkLCAyNiBNYXkgMjAyMSBhdCAxMzo0NiwgQ2hyaXN0aWFuIEvDtm5pZyA8Y2hyaXN0 aWFuLmtvZW5pZ0BhbWQuY29tPiB3cm90ZToKPiA+Pj4+IEFtIDI2LjA1LjIxIHVtIDEzOjMxIHNj aHJpZWIgRGFuaWVsIFN0b25lOgo+ID4+Pj4+IEhvdyB3b3VsZCB3ZSBpbnNlcnQgYSBzeW5jb2Jq K3ZhbCBpbnRvIGEgcmVzdiB0aG91Z2g/IExpa2UsIGlmIHdlIHBhc3MKPiA+Pj4+PiBhbiB1bm1h dGVyaWFsaXNlZCBzeW5jb2JqK3ZhbCBoZXJlIHRvIGluc2VydCBpbnRvIHRoZSByZXN2LCB0aGVu IGFuCj4gPj4+Pj4gaW1wbGljaXQtb25seSBtZWRpYSB1c2VyIChvciBLTVMpIGdvZXMgdG8gc3lu YyBhZ2FpbnN0IHRoZSByZXN2LCB3aGF0Cj4gPj4+Pj4gaGFwcGVucz8KPiA+Pj4+IFdlbGwgdGhp cyBpcyBmb3IgZXhwb3J0aW5nLCBub3QgaW1wb3J0aW5nLiBTbyB3ZSBkb24ndCBuZWVkIHRvIHdv cnJ5Cj4gPj4+PiBhYm91dCB0aGF0Lgo+ID4+Pj4KPiA+Pj4+IEl0J3MganVzdCBteSB0aGlua2lu ZyBiZWNhdXNlIHRoZSBkcm1fc3luY29iaiBpcyB0aGUgYmFja2luZyBvYmplY3Qgb24KPiA+Pj4+ IFZrU2VtYXBob3JlIGltcGxlbWVudGF0aW9ucyB0aGVzZSBkYXlzLCBpc24ndCBpdD8KPiA+Pj4g WWVhaCwgSSBjYW4gc2VlIHRoYXQgdG8gYW4gZXh0ZW50LiBCdXQgdGhlbiBiaW5hcnkgdnMuIHRp bWVsaW5lCj4gPj4+IHN5bmNvYmpzIGFyZSB2ZXJ5IGRpZmZlcmVudCBpbiB1c2UgKHdoaWNoIGlz IHVuZm9ydHVuYXRlIHRiaCksIGFuZAo+ID4+PiB0aGVuIHdlIGhhdmUgYW4gYXN5bW1ldHJ5IGJl dHdlZW4gc3luY29iaiBleHBvcnQgJiBzeW5jX2ZpbGUgaW1wb3J0Lgo+ID4+Pgo+ID4+PiBZb3Un cmUgcmlnaHQgdGhhdCB3ZSBkbyB3YW50IGEgc3luY29iaiB0aG91Z2guCj4gPiBJJ20gbm90IGNv bnZpbmNlZC4gIFNvbWUgcGVvcGxlIHNlZW0gdG8gdGhpbmsgdGhhdCB3ZSBoYXZlIGEgZGlyZWN0 Cj4gPiBwcm9ncmVzc2lvbiBvZiBzdXBlcmlvcml0eTogc3luY19maWxlIDwgc3luY29iaiA8IHRp bWVsaW5lIHN5bmNvYmouICBJCj4gPiBkb24ndCB0aGluayB0aGlzIGlzIHRydWUuICBUaGV5IGVh Y2ggc2VydmUgZGlmZmVyZW50IHB1cnBvc2VzLiAgQQo+ID4gc3luY19maWxlIGlzIGEgaGFuZGxl IHRvIGEgc2luZ2xlIGltbXV0YWJsZSBmZW5jZSBvcGVyYXRpb24gKGEKPiA+IGRtYV9mZW5jZSop LiAgQSBzeW5jb2JqIGlzIGEgY29udGFpbmVyIGZvciBhIGZlbmNlIGFuZCBpcywgYnkKPiA+IGRl ZmluaXRpb24sIG11dGFibGUgKGEgZG1hX2ZlbmNlKiopLiAgQSB0aW1lbGluZSBzeW5jb2JqIGlz IGEKPiA+IGNvbnN0cnVjdCB0aGF0IGxldHMgdXMgaW1wbGVtZW50IFZLX0tIUl90aW1lbGluZV9z ZW1hcGhvcmUgd2l0aCBvbmx5Cj4gPiBpbW11dGFibGUgZmluaXRlLXRpbWUgKG5vdCBmdXR1cmUp IGZlbmNlcy4KPiA+Cj4gPiAgRnJvbSBhIFdTSSBwcm90b2NvbCBQb1YsIGl0J3Mgc29tZXRpbWVz IG5pY2VyIHRvIHBhc3MgYSBjb250YWluZXIKPiA+IG9iamVjdCBvbmNlIGFuZCB0aGVuIHBhc3Mg YSBzZXJpYWwgb3IgYSBzaW1wbGUgIkkganVzdCB1cGRhdGVkIGl0Igo+ID4gc2lnbmFsIGV2ZXJ5 IHRpbWUgaW5zdGVhZCBvZiBhIG5ldyBGRC4gIEl0IGNlcnRhaW5seSBtYWtlcyBhbGwgdGhlCj4g PiAid2hvIGNsb3NlcyB0aGlzLCBhZ2Fpbj8iIHNlbWFudGljcyBlYXNpZXIuICBCdXQgd2Ugc2hv dWxkbid0IHRoaW5rIG9mCj4gPiBzeW5jb2JqIGFzIGJlaW5nIGJldHRlciB0aGFuIHN5bmNfZmls ZS4gIFdpdGggYmluYXJ5IHN5bmNvYmosIGl0Cj4gPiByZWFsbHkgaXMgdGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiBwYXNzaW5nIGEgZG1hX2ZlbmNlKiB2cy4gYQo+ID4gZG1hX2ZlbmNlKiouICBTb21l dGltZXMgeW91IHdhbnQgb25lIGFuZCBzb21ldGltZXMgeW91IHdhbnQgdGhlIG90aGVyLgo+ID4g VGhlIHJlYWwgcGl0eSwgSU1PLCBpcyB0aGF0IHRoZSB1QVBJIGlzIHNjYXR0ZXJlZCBldmVyeXdo ZXJlLgo+ID4KPiA+Pj4gVGhpcyBpcyBwcm9iYWJseSBub3QKPiA+Pj4gcHJhY3RpY2FsIGR1ZSB0 byBzbWFzaGluZyB1QVBJIHRvIGJpdHMsIGJ1dCBpZiB3ZSBjb3VsZCB3aW5kIHRoZSBjbG9jawo+ ID4+PiBiYWNrIGEgY291cGxlIG9mIHllYXJzLCBJIHN1c3BlY3QgdGhlIGludGVyZmFjZSB3ZSB3 YW50IGlzIHRoYXQgZXhwb3J0Cj4gPj4+IGNhbiBlaXRoZXIgZXhwb3J0IGEgc3luY19maWxlIG9y IGEgYmluYXJ5IHN5bmNvYmosIGFuZCBmdXJ0aGVyIHRoYXQKPiA+Pj4gYmluYXJ5IHN5bmNvYmpz IGNvdWxkIHRyYW5zcGFyZW50bHkgYWN0IGFzIHRpbWVsaW5lIHNlbWFwaG9yZXMgYnkKPiA+Pj4g bWFwcGluZyBhbnkgdmFsdWUgKGVpdGhlciB3YWl0IG9yIHNpZ25hbCkgdG8gdGhlIGJpbmFyeSBz aWduYWwuIEluCj4gPj4+IGhpbmRzaWdodCwgd2Ugc2hvdWxkIHByb2JhYmx5IGp1c3QgbmV2ZXIg aGF2ZSBoYWQgYmluYXJ5IHN5bmNvYmouIE9oCj4gPj4+IHdlbGwuCj4gPj4gV2VsbCB0aGUgbGF0 ZXIgaXMgdGhlIGNhc2UgSUlSQy4gRG9uJ3QgYXNrIG1lIGZvciB0aGUgZGV0YWlsIHNlbWFudGlj cywKPiA+PiBidXQgaW4gZ2VuZXJhbCB0aGUgZHJtX3N5bmNvYmogaW4gdGltZWxpbmUgbW9kZSBp cyBjb21wYXRpYmxlIHRvIHRoZQo+ID4+IGJpbmFyeSBtb2RlLgo+ID4+Cj4gPj4gVGhlIHN5bmNf ZmlsZSBpcyBhbHNvIGltcG9ydC9leHBvcnRhYmxlIHRvIGEgY2VydGFpbiBkcm1fc3luY29iago+ ID4+IHRpbWVsaW5lIHBvaW50IChvciBhcyBiaW5hcnkgc2lnbmFsKS4gU28gbm8gYmlnIGRlYWws IHdlIGFyZSBhbGwKPiA+PiBjb21wYXRpYmxlIGhlcmUgOikKPiA+Pgo+ID4+IEkganVzdCB0aG91 Z2h0IHRoYXQgaXQgbWlnaHQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byByZXR1cm4gYSBkcm1fc3lu Y29iago+ID4+IGRpcmVjdGx5IGluc3RlYWQgb2YgYSBzeW5jX2ZpbGUuCj4gPiBNYXliZS4gIEkn bSBub3QgY29udmluY2VkIHRoYXQncyBiZXR0ZXIuICBJbiB0aGUgY3VycmVudCBNZXNhIFdTSQo+ ID4gY29kZSwgaXQnZCBhY3R1YWxseSBiZSBxdWl0ZSBhIHBhaW4uCj4gPgo+ID4gLS1KYXNvbgo+ Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkludGVsLWdm eCBtYWlsaW5nIGxpc3QKSW50ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludGVsLWdmeAo= 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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 9A0FBC4707F for ; Thu, 27 May 2021 15:39:24 +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 4DD21613B4 for ; Thu, 27 May 2021 15:39:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DD21613B4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jlekstrand.net 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 76B7B6E073; Thu, 27 May 2021 15:39:23 +0000 (UTC) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by gabe.freedesktop.org (Postfix) with ESMTPS id EDEA36E046 for ; Thu, 27 May 2021 15:39:21 +0000 (UTC) Received: by mail-yb1-xb2f.google.com with SMTP id v77so1292162ybi.3 for ; Thu, 27 May 2021 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jlekstrand-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=0AJfGN9E24XOsXAh7WyvJAru8MAlsyAmbHYQ6ndEqGE=; b=n0F8zlpJx+uKh8o5Eb40GCmDKjYOcoc9/SENacxnC/hS7av8ZDuIP9s55YZ52hbKSX Ua4VyGj+eRrwUi9A0upW/MPR3aLyqYEJY1HE7kdLXY+voTKyQApuNOzyPxTB25cyS9ax HnVmFCK4cam/1mn/yEQ4O5I0WHFkzNjrfjijrTz4tHhMKws3PrgRdQd8XuB6mKMoCNt/ HAr4GWpch/GCBG4d+3RaVHYAasUq8TPp3Y5VN646bDjxyzpsOkz7VJyijpIfcI1o/2M0 N89koBjF/8LRSv3bN9PLjPhM8ihHR1mbvpIBL9eJT72DyiDFU43DQmcfvd614QQVJ+H4 eMAw== 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:content-transfer-encoding; bh=0AJfGN9E24XOsXAh7WyvJAru8MAlsyAmbHYQ6ndEqGE=; b=P68JeU6lpgEtz3t/ElHAtslYXmCCc/lDUw2ja8NUW+JQ68wj3Rdv1eZYjm/5QZAnRm Qser5dq9MGPqa+9hnAOy2K0NaJVfOX8G2rprTUT/LJwc0OHhSYTYcz/vNFhgEdZs2vCS 492JVJ7QxCpKCpi3GRwanZmb7SI79kAb1GK8dW5gOHhQgG4/KiweMaj72AZGfW4w7rKN Hyengy3UgeSOzdBc5lCH7fhMwdj2XVoyMnm2N7j5D/xpxpkAAtSMbfoc08ERN3lSoBEP 4QPmcwfjx8JlJKQqtYCHzK0+5BzPIeWfdXFdwuTLo9LUUTaRnN00Mzx7HE3OPOANUxhu B9qg== X-Gm-Message-State: AOAM5301z6bQaU26EVchN6IYCT62NAiV54Dv6KsYjvzeuBIQaJKvRblr Uv83Z7MeIj9hBOKscLYkg1slDvMKnoFztoesoVgr9Q== X-Google-Smtp-Source: ABdhPJzqyepqasUorYM2LiZLA/CiqbdyPtZhS/6eEiDfwPJ6j4Mth3MU7LV/HlJqdQrbg4ptJQcVI1Ko+TLYRQ9kBvo= X-Received: by 2002:a05:6902:705:: with SMTP id k5mr5504628ybt.241.1622129960996; Thu, 27 May 2021 08:39:20 -0700 (PDT) MIME-Version: 1.0 References: <20210525211753.1086069-1-jason@jlekstrand.net> <20210525211753.1086069-6-jason@jlekstrand.net> <770eb698-1dde-9e46-da83-44911d96abec@amd.com> In-Reply-To: From: Jason Ekstrand Date: Thu, 27 May 2021 10:39:09 -0500 Message-ID: Subject: Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11) To: =?UTF-8?Q?Christian_K=C3=B6nig?= , Maling list - DRI developers , Simon Ser , Daniel Vetter , Sumit Semwal , Intel GFX , Daniel Stone Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, May 27, 2021 at 4:49 AM Christian K=C3=B6nig wrote: > > Am 26.05.21 um 19:42 schrieb Jason Ekstrand: > > On Wed, May 26, 2021 at 6:02 AM Christian K=C3=B6nig > > wrote: > >> Regarding that, why do we actually use a syncfile and not a drm_syncob= j > >> here? > > A sync file is a userspace handle to a dma_fence which is exactly what > > we're grabbing from the dma-buf so it's a better match. A syncobj, on > > the other hand, is a container for fences. If we really want it in a > > syncobj (which we may), we can use another ioctl to stuff it in there. > > The only thing making this work in terms of syncobj would save us is a > > little ioctl overhead. In my Mesa patches, we do stuff it in a > > syncobj but, instead of acting on the syncobj directly, we go through > > vkSemaphoreImportFd() which is way more convenient for generic WSI > > code. > > Yeah, that is a really good argument. > > > It also works nicer because a sync_file is a pretty generic construct > > but a syncobj is a DRM construct. This lets us do the export in an > > entirely driver-generic way without even having access to a DRM fd. > > It all happens as an ioctl on the dma-buf. > > Well that's an even better argument and I think the killer argument here. Cool. > We should probably mention that on the commit message as a single > sentence somewhere. Happy to do so. How does this sound: By making this an ioctl on the dma-buf itself, it allows this new functionality to be used in an entirely driver-agnostic way without having access to a DRM fd. This makes it ideal for use in driver-generic code in Mesa or in a client such as a compositor where the DRM fd may be hard to reach. > BTW: You replied exclusively to me. Was that intentionally? I don't > think so :) Oops... I've re-added the whole lot in this reply. --Jason > Regards, > Christian. > > > > > On Wed, May 26, 2021 at 8:23 AM Christian K=C3=B6nig > > wrote: > > > >> Am 26.05.21 um 15:12 schrieb Daniel Stone: > >>> On Wed, 26 May 2021 at 13:46, Christian K=C3=B6nig 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. > > I'm not convinced. Some people seem to think that we have a direct > > progression of superiority: sync_file < syncobj < timeline syncobj. I > > don't think this is true. They each serve different purposes. A > > sync_file is a handle to a single immutable fence operation (a > > dma_fence*). A syncobj is a container for a fence and is, by > > definition, mutable (a dma_fence**). A timeline syncobj is a > > construct that lets us implement VK_KHR_timeline_semaphore with only > > immutable finite-time (not future) fences. > > > > From a WSI protocol PoV, it's sometimes nicer to pass a container > > object once and then pass a serial or a simple "I just updated it" > > signal every time instead of a new FD. It certainly makes all the > > "who closes this, again?" semantics easier. But we shouldn't think of > > syncobj as being better than sync_file. With binary syncobj, it > > really is the difference between passing a dma_fence* vs. a > > dma_fence**. Sometimes you want one and sometimes you want the other. > > The real pity, IMO, is that the uAPI is scattered everywhere. > > > >>> This is probably not > >>> practical due to smashing uAPI to bits, but if we could wind the cloc= k > >>> back a couple of years, I suspect the interface we want is that expor= t > >>> 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_synco= bj > >> directly instead of a sync_file. > > Maybe. I'm not convinced that's better. In the current Mesa WSI > > code, it'd actually be quite a pain. > > > > --Jason >