Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp882319imu; Mon, 5 Nov 2018 10:09:28 -0800 (PST) X-Google-Smtp-Source: AJdET5cAyKTrOYjHsX2a4Tp+w9I9luB6wCASpMTHIPa8XCyYs3kkAnNFQxfwEOOMjBzGNWG1oj/1 X-Received: by 2002:a62:1a55:: with SMTP id a82-v6mr16278043pfa.133.1541441368276; Mon, 05 Nov 2018 10:09:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541441368; cv=none; d=google.com; s=arc-20160816; b=nwIM0Ek7VdqWaeWgaAD2XColW23eXfRzp/1wZx7W9VhR1kDu2eJaTod4QMcElZcJ67 I9r1zkTr+n3mviQQRdD8M/LLi4GUNXP2f0sRDYdErDHsGSAqPDIhDOD2IjqTQVPDaXu0 nBpYP1Z77H4t0m/vtGhuehQgDMfGIunNiIsJqbIJAm5WiDSEPYZMLJN3q+JWPtWdjCpY QQrXNX2xmpahFTSQObED/yvA9BEiwqtxln0jko0d+kK1LWvAPV3+VDdpax1VCNtrRKAx fFas8He7DGyGbgxP1DeTpXg4ka6tSjQhsqpLqfVH7Vr6ms6lcfnVc1bPJCXvXKB+Y844 cK0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=RpiBl2nwOV0Zl12KyucCTEjoCjLeNI7u0YxZBwNTF/Q=; b=Q4briOAo3f4EzTBpfqWRrnW3FjKR7mAzNlbuuey3kruE+AAWGYQc4qvr20V2kx/mHB wv9rlC+aZd52s7q9WTjrtuvfjYRReecTICPO/Tieo5AorgedbbyJi6JSuPOGcPm6AXp4 aKQ+mcfSe7NNfMI4u/SL37ELnNT6whXTU4sbeqak7/VxsJ/jxtsttcK1NJPWiqvFHDkV mrgSTbL8lefBhq//0EPyL33EcaKcbu0z1Z/MyGgK41vnTdJNPguARIuE8lyiawP1aVVc 55QlQ/VuDq4X+EyY7o9pWR/CgWZ3WrjZuGqQevVyW4kJGY/DE3hCVoXIiBjTL7K2okGF HLxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w64-v6si40340245pfw.101.2018.11.05.10.09.10; Mon, 05 Nov 2018 10:09:28 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387796AbeKFD3M (ORCPT + 99 others); Mon, 5 Nov 2018 22:29:12 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:50274 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387640AbeKFD3M (ORCPT ); Mon, 5 Nov 2018 22:29:12 -0500 Received: from [IPv6:2a02:8109:92c0:207d:797b:9adc:b59e:ee7c] (unknown [IPv6:2a02:8109:92c0:207d:797b:9adc:b59e:ee7c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: robertfoss) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 5445D260E1F; Mon, 5 Nov 2018 18:08:20 +0000 (GMT) Subject: Re: [PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization To: Emil Velikov Cc: David Airlie , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , "open list:VIRTIO GPU DRIVER" , Gustavo Padovan , Gerd Hoffmann , Emil Velikov References: <20181105114152.2088-1-robert.foss@collabora.com> <20181105114152.2088-4-robert.foss@collabora.com> From: Robert Foss Message-ID: <995bbb2f-ecaa-e4f5-045b-b9cc7b287a66@collabora.com> Date: Mon, 5 Nov 2018 19:08:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Heya, On 2018-11-05 18:25, Emil Velikov wrote: > On Mon, 5 Nov 2018 at 11:42, Robert Foss wrote: >> >> When the execbuf call receives an in-fence it will get the dma_fence >> related to that fence fd and wait on it before submitting the draw call. >> >> On the out-fence side we get fence returned by the submitted draw call >> and attach it to a sync_file and send the sync_file fd to userspace. On >> error -1 is returned to userspace. >> >> Signed-off-by: Gustavo Padovan >> Signed-off-by: Robert Foss >> Suggested-by: Rob Herring >> Reviewed-by: Emil Velikov >> --- >> >> Changes since v3: >> - Move all in_fence handling to the same VIRTGPU_EXECBUF_FENCE_FD_IN block > Fwiw my suggestion was to explicitly document whether the IOCTL can > support, simultaneously, IN and OUT fence. I can't say I understood that part, but I'll happily spin another revision with more documentation added. But the change above does not entirely come from your feedback. While looking into how other drivers do this, an issue in msm was found. Since this code is being added to virtgpu now, we might as well do the right thing here, and also end up with all of the in fence handling in a single chunk. > Merging the two patches makes things a bit meh. But as before - it's > for Gerd to make the final call. > > -Emil > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >