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.2 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 236D0C4332D for ; Fri, 20 Mar 2020 08:50:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E94C720752 for ; Fri, 20 Mar 2020 08:50:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726767AbgCTIuf (ORCPT ); Fri, 20 Mar 2020 04:50:35 -0400 Received: from mail.netline.ch ([148.251.143.178]:51038 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726232AbgCTIuf (ORCPT ); Fri, 20 Mar 2020 04:50:35 -0400 Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id B834F2A6016; Fri, 20 Mar 2020 09:50:32 +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 RaTPwCQfUc8e; Fri, 20 Mar 2020 09:50:32 +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 2838A2A6042; Fri, 20 Mar 2020 09:50:32 +0100 (CET) Received: from localhost ([::1]) by thor with esmtp (Exim 4.93) (envelope-from ) id 1jFDM7-0007vl-16; Fri, 20 Mar 2020 09:50:15 +0100 Subject: Re: Plumbing explicit synchronization through the Linux ecosystem To: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= , Daniel Vetter 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> <20200319105129.GF2363188@phenom.ffwll.local> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <0b547156-ea58-90ab-1ad0-36d8cc433f90@daenzer.net> Date: Fri, 20 Mar 2020 09:50:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.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-19 8:54 p.m., Marek Olšák wrote: > On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, > wrote: >> >> Yeah, this is entirely about the programming model visible to >> userspace. There shouldn't be any impact on the driver's choice of >> a top vs. bottom of the gpu pipeline used for synchronization, >> that's entirely up to what you're hw/driver/scheduler can pull >> off. >> >> Doing a full gfx pipeline flush for shared buffers, when your hw >> can do be, sounds like an issue to me that's not related to this >> here at all. It might be intertwined with amdgpu's special >> interpretation of dma_resv fences though, no idea. We might need to >> revamp all that. But for a userspace client that does nothing fancy >> (no multiple render buffer targets in one bo, or vk style "I write >> to everything all the time, perhaps" stuff) there should be 0 perf >> difference between implicit sync through dma_resv and explicit sync >> through sync_file/syncobj/dma_fence directly. >> >> If there is I'd consider that a bit a driver bug. > > Last time I checked, there was no fence sync in gnome shell and > compiz after an app passes a buffer to it. They are not required (though encouraged) to do that. > So drivers have to invent hacks to work around it and decrease > performance. It's not a driver bug. > > Implicit sync really means that apps and compositors don't sync, so > the driver has to guess when it should sync. Making implicit sync work correctly is ultimately the kernel driver's responsibility. It sounds like radeonsi is having to work around the amdgpu/radeon kernel driver(s) not fully living up to this responsibility. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer