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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 8B065C10F29 for ; Tue, 17 Mar 2020 10:02:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 684BA205ED for ; Tue, 17 Mar 2020 10:02:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725868AbgCQKCD (ORCPT ); Tue, 17 Mar 2020 06:02:03 -0400 Received: from mail.netline.ch ([148.251.143.178]:41830 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725730AbgCQKCC (ORCPT ); Tue, 17 Mar 2020 06:02:02 -0400 Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id 4E8EA2A6042; Tue, 17 Mar 2020 11:01:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at netline-mail3.netline.ch Received: from netline-mail3.netline.ch ([127.0.0.1]) by localhost (netline-mail3.netline.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DxoYdUv3L313; Tue, 17 Mar 2020 11:01:59 +0100 (CET) Received: from thor (252.80.76.83.dynamic.wline.res.cust.swisscom.ch [83.76.80.252]) by netline-mail3.netline.ch (Postfix) with ESMTPSA id 91A072A6016; Tue, 17 Mar 2020 11:01:58 +0100 (CET) Received: from [::1] by thor with esmtp (Exim 4.93) (envelope-from ) id 1jE92r-000epK-Rh; Tue, 17 Mar 2020 11:01:57 +0100 Subject: Re: Plumbing explicit synchronization through the Linux ecosystem To: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Cc: Daniel Vetter , xorg-devel , Maling list - DRI developers , "wayland-devel @ lists . freedesktop . org" , Discussion of the development of and with GStreamer , Jason Ekstrand , ML mesa-dev , linux-media@vger.kernel.org References: <170e13edbb0.27ad.c6988b7ea6112e3e892765a0d4287e0c@jlekstrand.net> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: Date: Tue, 17 Mar 2020 11:01:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On 2020-03-16 7:33 p.m., Marek Olšák wrote: > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote: >> On 2020-03-16 4:50 a.m., Marek Olšák wrote: >>> The synchronization works because the Mesa driver waits for idle (drains >>> the GFX pipeline) at the end of command buffers and there is only 1 >>> graphics queue, so everything is ordered. >>> >>> The GFX pipeline runs asynchronously to the command buffer, meaning the >>> command buffer only starts draws and doesn't wait for completion. If the >>> Mesa driver didn't wait at the end of the command buffer, the command >>> buffer would finish and a different process could start execution of its >>> own command buffer while shaders of the previous process are still >> running. >>> >>> If the Mesa driver submits a command buffer internally (because it's >> full), >>> it doesn't wait, so the GFX pipeline doesn't notice that a command buffer >>> ended and a new one started. >>> >>> The waiting at the end of command buffers happens only when the flush is >>> external (Swap buffers, glFlush). >>> >>> It's a performance problem, because the GFX queue is blocked until the >> GFX >>> pipeline is drained at the end of every frame at least. >>> >>> So explicit fences for SwapBuffers would help. >> >> Not sure what difference it would make, since the same thing needs to be >> done for explicit fences as well, doesn't it? > > No. Explicit fences don't require userspace to wait for idle in the command > buffer. Fences are signalled when the last draw is complete and caches are > flushed. Before that happens, any command buffer that is not dependent on > the fence can start execution. There is never a need for the GPU to be idle > if there is enough independent work to do. I don't think explicit fences in the context of this discussion imply using that different fence signalling mechanism though. My understanding is that the API proposed by Jason allows implicit fences to be used as explicit ones and vice versa, so presumably they have to use the same signalling mechanism. Anyway, maybe the different fence signalling mechanism you describe could be used by the amdgpu kernel driver in general, then Mesa could drop the waits for idle and get the benefits with implicit sync as well? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer