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=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 D4F18C433E3 for ; Wed, 22 Jul 2020 13:12:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B36FF20717 for ; Wed, 22 Jul 2020 13:12:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=shipmail.org header.i=@shipmail.org header.b="m8x/rX9A" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726003AbgGVNMN (ORCPT ); Wed, 22 Jul 2020 09:12:13 -0400 Received: from ste-pvt-msa1.bahnhof.se ([213.80.101.70]:35822 "EHLO ste-pvt-msa1.bahnhof.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725878AbgGVNMM (ORCPT ); Wed, 22 Jul 2020 09:12:12 -0400 Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id D70B13F634; Wed, 22 Jul 2020 15:12:09 +0200 (CEST) Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=m8x/rX9A; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpwrYAHQP3Iq; Wed, 22 Jul 2020 15:12:09 +0200 (CEST) Received: from mail1.shipmail.org (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) (Authenticated sender: mb878879) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 420893F29E; Wed, 22 Jul 2020 15:12:05 +0200 (CEST) Received: from [192.168.0.100] (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) by mail1.shipmail.org (Postfix) with ESMTPSA id 7831D362551; Wed, 22 Jul 2020 15:12:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1595423525; bh=BkLRqDnF6XeEiFgBNy2htn8KfcdCEjHm5mJt4RvFSnY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=m8x/rX9A/5dWwW9deLLc6aLIe4nKw3T+GjV3Mey9FdcHPjjgoDT8c+S8HtNfUdSry hyK2SRYBZv+xlR+pd8m2hEh+pGKmkJMiDw0KlyvoimmBHTzNHUQfUUCgDwzI4bxZ8g QuFArKmKCeFm9S1vgSmn0RJWQHG/kF/iJyd5XVgo= Subject: Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea To: Daniel Vetter Cc: Dave Airlie , =?UTF-8?Q?Christian_K=c3=b6nig?= , Daniel Stone , linux-rdma , Intel Graphics Development , Maarten Lankhorst , DRI Development , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Steve Pronovost , amd-gfx mailing list , Jason Ekstrand , Jesse Natalie , Daniel Vetter , Thomas Hellstrom , Mika Kuoppala , Felix Kuehling , Linux Media Mailing List References: <20200707201229.472834-4-daniel.vetter@ffwll.ch> <20200709123339.547390-1-daniel.vetter@ffwll.ch> <93b673b7-bb48-96eb-dc2c-bd4f9304000e@shipmail.org> <20200721074157.GB3278063@phenom.ffwll.local> <3603bb71-318b-eb53-0532-9daab62dce86@amd.com> <57a5eb9d-b74f-8ce4-7199-94e911d9b68b@shipmail.org> <805c49b7-f0b3-45dc-5fe3-b352f0971527@shipmail.org> <92393d26-d863-aac6-6d27-53cad6854e13@shipmail.org> <8fd999f2-cbf6-813c-6ad4-131948fb5cc5@shipmail.org> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= Message-ID: <697d1b5e-5d1c-1655-23f8-7a3f652606f3@shipmail.org> Date: Wed, 22 Jul 2020 15:12:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On 2020-07-22 14:41, Daniel Vetter wrote: > > Ah I think I misunderstood which options you want to compare here. I'm > not sure how much pain fixing up "dma-fence as memory fence" really > is. That's kinda why I want a lot more testing on my annotation > patches, to figure that out. Not much feedback aside from amdgpu and > intel, and those two drivers pretty much need to sort out their memory > fence issues anyway (because of userptr and stuff like that). > > The only other issues outside of these two drivers I'm aware of: > - various scheduler drivers doing allocations in the drm/scheduler > critical section. Since all arm-soc drivers have a mildly shoddy > memory model of "we just pin everything" they don't really have to > deal with this. So we might just declare arm as a platform broken and > not taint the dma-fence critical sections with fs_reclaim. Otoh we > need to fix this for drm/scheduler anyway, I think best option would > be to have a mempool for hw fences in the scheduler itself, and at > that point fixing the other drivers shouldn't be too onerous. > > - vmwgfx doing a dma_resv in the atomic commit tail. Entirely > orthogonal to the entire memory fence discussion. With vmwgfx there is another issue that is hit when the gpu signals an error. At that point the batch might be restarted with a new meta command buffer that needs to be allocated out of a dma pool. in the fence critical section. That's probably a bit nasty to fix, but not impossible. > > I'm pretty sure there's more bugs, I just haven't heard from them yet. > Also due to the opt-in nature of dma-fence we can limit the scope of > what we fix fairly naturally, just don't put them where no one cares > :-) Of course that also hides general locking issues in dma_fence > signalling code, but well *shrug*. Hmm, yes. Another potential big problem would be drivers that want to use gpu page faults in the dma-fence critical sections with the batch-based programming model. /Thomas 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=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 A635BC433E7 for ; Wed, 22 Jul 2020 13:12:15 +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 7479B20717 for ; Wed, 22 Jul 2020 13:12:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=shipmail.org header.i=@shipmail.org header.b="m8x/rX9A" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7479B20717 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shipmail.org 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 072B06E817; Wed, 22 Jul 2020 13:12:14 +0000 (UTC) Received: from ste-pvt-msa1.bahnhof.se (ste-pvt-msa1.bahnhof.se [213.80.101.70]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12D676E366; Wed, 22 Jul 2020 13:12:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id D70B13F634; Wed, 22 Jul 2020 15:12:09 +0200 (CEST) Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=m8x/rX9A; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpwrYAHQP3Iq; Wed, 22 Jul 2020 15:12:09 +0200 (CEST) Received: from mail1.shipmail.org (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) (Authenticated sender: mb878879) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 420893F29E; Wed, 22 Jul 2020 15:12:05 +0200 (CEST) Received: from [192.168.0.100] (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) by mail1.shipmail.org (Postfix) with ESMTPSA id 7831D362551; Wed, 22 Jul 2020 15:12:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1595423525; bh=BkLRqDnF6XeEiFgBNy2htn8KfcdCEjHm5mJt4RvFSnY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=m8x/rX9A/5dWwW9deLLc6aLIe4nKw3T+GjV3Mey9FdcHPjjgoDT8c+S8HtNfUdSry hyK2SRYBZv+xlR+pd8m2hEh+pGKmkJMiDw0KlyvoimmBHTzNHUQfUUCgDwzI4bxZ8g QuFArKmKCeFm9S1vgSmn0RJWQHG/kF/iJyd5XVgo= Subject: Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea To: Daniel Vetter References: <20200707201229.472834-4-daniel.vetter@ffwll.ch> <20200709123339.547390-1-daniel.vetter@ffwll.ch> <93b673b7-bb48-96eb-dc2c-bd4f9304000e@shipmail.org> <20200721074157.GB3278063@phenom.ffwll.local> <3603bb71-318b-eb53-0532-9daab62dce86@amd.com> <57a5eb9d-b74f-8ce4-7199-94e911d9b68b@shipmail.org> <805c49b7-f0b3-45dc-5fe3-b352f0971527@shipmail.org> <92393d26-d863-aac6-6d27-53cad6854e13@shipmail.org> <8fd999f2-cbf6-813c-6ad4-131948fb5cc5@shipmail.org> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= Message-ID: <697d1b5e-5d1c-1655-23f8-7a3f652606f3@shipmail.org> Date: Wed, 22 Jul 2020 15:12:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US 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: , Cc: Felix Kuehling , Daniel Stone , linux-rdma , Intel Graphics Development , DRI Development , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Steve Pronovost , amd-gfx mailing list , Jason Ekstrand , Jesse Natalie , Daniel Vetter , Thomas Hellstrom , Linux Media Mailing List , =?UTF-8?Q?Christian_K=c3=b6nig?= , Mika Kuoppala Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2020-07-22 14:41, Daniel Vetter wrote: > > Ah I think I misunderstood which options you want to compare here. I'm > not sure how much pain fixing up "dma-fence as memory fence" really > is. That's kinda why I want a lot more testing on my annotation > patches, to figure that out. Not much feedback aside from amdgpu and > intel, and those two drivers pretty much need to sort out their memory > fence issues anyway (because of userptr and stuff like that). > > The only other issues outside of these two drivers I'm aware of: > - various scheduler drivers doing allocations in the drm/scheduler > critical section. Since all arm-soc drivers have a mildly shoddy > memory model of "we just pin everything" they don't really have to > deal with this. So we might just declare arm as a platform broken and > not taint the dma-fence critical sections with fs_reclaim. Otoh we > need to fix this for drm/scheduler anyway, I think best option would > be to have a mempool for hw fences in the scheduler itself, and at > that point fixing the other drivers shouldn't be too onerous. > > - vmwgfx doing a dma_resv in the atomic commit tail. Entirely > orthogonal to the entire memory fence discussion. With vmwgfx there is another issue that is hit when the gpu signals an error. At that point the batch might be restarted with a new meta command buffer that needs to be allocated out of a dma pool. in the fence critical section. That's probably a bit nasty to fix, but not impossible. > > I'm pretty sure there's more bugs, I just haven't heard from them yet. > Also due to the opt-in nature of dma-fence we can limit the scope of > what we fix fairly naturally, just don't put them where no one cares > :-) Of course that also hides general locking issues in dma_fence > signalling code, but well *shrug*. Hmm, yes. Another potential big problem would be drivers that want to use gpu page faults in the dma-fence critical sections with the batch-based programming model. /Thomas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 8B768C433E4 for ; Wed, 22 Jul 2020 13:12:14 +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 608F320771 for ; Wed, 22 Jul 2020 13:12:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=shipmail.org header.i=@shipmail.org header.b="m8x/rX9A" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 608F320771 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shipmail.org 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 8D6A96E366; Wed, 22 Jul 2020 13:12:13 +0000 (UTC) Received: from ste-pvt-msa1.bahnhof.se (ste-pvt-msa1.bahnhof.se [213.80.101.70]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12D676E366; Wed, 22 Jul 2020 13:12:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id D70B13F634; Wed, 22 Jul 2020 15:12:09 +0200 (CEST) Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=m8x/rX9A; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpwrYAHQP3Iq; Wed, 22 Jul 2020 15:12:09 +0200 (CEST) Received: from mail1.shipmail.org (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) (Authenticated sender: mb878879) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 420893F29E; Wed, 22 Jul 2020 15:12:05 +0200 (CEST) Received: from [192.168.0.100] (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) by mail1.shipmail.org (Postfix) with ESMTPSA id 7831D362551; Wed, 22 Jul 2020 15:12:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1595423525; bh=BkLRqDnF6XeEiFgBNy2htn8KfcdCEjHm5mJt4RvFSnY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=m8x/rX9A/5dWwW9deLLc6aLIe4nKw3T+GjV3Mey9FdcHPjjgoDT8c+S8HtNfUdSry hyK2SRYBZv+xlR+pd8m2hEh+pGKmkJMiDw0KlyvoimmBHTzNHUQfUUCgDwzI4bxZ8g QuFArKmKCeFm9S1vgSmn0RJWQHG/kF/iJyd5XVgo= To: Daniel Vetter References: <20200707201229.472834-4-daniel.vetter@ffwll.ch> <20200709123339.547390-1-daniel.vetter@ffwll.ch> <93b673b7-bb48-96eb-dc2c-bd4f9304000e@shipmail.org> <20200721074157.GB3278063@phenom.ffwll.local> <3603bb71-318b-eb53-0532-9daab62dce86@amd.com> <57a5eb9d-b74f-8ce4-7199-94e911d9b68b@shipmail.org> <805c49b7-f0b3-45dc-5fe3-b352f0971527@shipmail.org> <92393d26-d863-aac6-6d27-53cad6854e13@shipmail.org> <8fd999f2-cbf6-813c-6ad4-131948fb5cc5@shipmail.org> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= Message-ID: <697d1b5e-5d1c-1655-23f8-7a3f652606f3@shipmail.org> Date: Wed, 22 Jul 2020 15:12:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Subject: Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea 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: , Cc: Felix Kuehling , Daniel Stone , linux-rdma , Intel Graphics Development , DRI Development , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Steve Pronovost , amd-gfx mailing list , Jesse Natalie , Daniel Vetter , Thomas Hellstrom , Linux Media Mailing List , =?UTF-8?Q?Christian_K=c3=b6nig?= , Mika Kuoppala Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 2020-07-22 14:41, Daniel Vetter wrote: > > Ah I think I misunderstood which options you want to compare here. I'm > not sure how much pain fixing up "dma-fence as memory fence" really > is. That's kinda why I want a lot more testing on my annotation > patches, to figure that out. Not much feedback aside from amdgpu and > intel, and those two drivers pretty much need to sort out their memory > fence issues anyway (because of userptr and stuff like that). > > The only other issues outside of these two drivers I'm aware of: > - various scheduler drivers doing allocations in the drm/scheduler > critical section. Since all arm-soc drivers have a mildly shoddy > memory model of "we just pin everything" they don't really have to > deal with this. So we might just declare arm as a platform broken and > not taint the dma-fence critical sections with fs_reclaim. Otoh we > need to fix this for drm/scheduler anyway, I think best option would > be to have a mempool for hw fences in the scheduler itself, and at > that point fixing the other drivers shouldn't be too onerous. > > - vmwgfx doing a dma_resv in the atomic commit tail. Entirely > orthogonal to the entire memory fence discussion. With vmwgfx there is another issue that is hit when the gpu signals an error. At that point the batch might be restarted with a new meta command buffer that needs to be allocated out of a dma pool. in the fence critical section. That's probably a bit nasty to fix, but not impossible. > > I'm pretty sure there's more bugs, I just haven't heard from them yet. > Also due to the opt-in nature of dma-fence we can limit the scope of > what we fix fairly naturally, just don't put them where no one cares > :-) Of course that also hides general locking issues in dma_fence > signalling code, but well *shrug*. Hmm, yes. Another potential big problem would be drivers that want to use gpu page faults in the dma-fence critical sections with the batch-based programming model. /Thomas _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx 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=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 3570AC433E2 for ; Wed, 22 Jul 2020 13:12:14 +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 09F7F20717 for ; Wed, 22 Jul 2020 13:12:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=shipmail.org header.i=@shipmail.org header.b="m8x/rX9A" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 09F7F20717 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shipmail.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AB2516E471; Wed, 22 Jul 2020 13:12:13 +0000 (UTC) Received: from ste-pvt-msa1.bahnhof.se (ste-pvt-msa1.bahnhof.se [213.80.101.70]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12D676E366; Wed, 22 Jul 2020 13:12:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id D70B13F634; Wed, 22 Jul 2020 15:12:09 +0200 (CEST) Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=m8x/rX9A; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpwrYAHQP3Iq; Wed, 22 Jul 2020 15:12:09 +0200 (CEST) Received: from mail1.shipmail.org (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) (Authenticated sender: mb878879) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 420893F29E; Wed, 22 Jul 2020 15:12:05 +0200 (CEST) Received: from [192.168.0.100] (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) by mail1.shipmail.org (Postfix) with ESMTPSA id 7831D362551; Wed, 22 Jul 2020 15:12:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1595423525; bh=BkLRqDnF6XeEiFgBNy2htn8KfcdCEjHm5mJt4RvFSnY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=m8x/rX9A/5dWwW9deLLc6aLIe4nKw3T+GjV3Mey9FdcHPjjgoDT8c+S8HtNfUdSry hyK2SRYBZv+xlR+pd8m2hEh+pGKmkJMiDw0KlyvoimmBHTzNHUQfUUCgDwzI4bxZ8g QuFArKmKCeFm9S1vgSmn0RJWQHG/kF/iJyd5XVgo= Subject: Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea To: Daniel Vetter References: <20200707201229.472834-4-daniel.vetter@ffwll.ch> <20200709123339.547390-1-daniel.vetter@ffwll.ch> <93b673b7-bb48-96eb-dc2c-bd4f9304000e@shipmail.org> <20200721074157.GB3278063@phenom.ffwll.local> <3603bb71-318b-eb53-0532-9daab62dce86@amd.com> <57a5eb9d-b74f-8ce4-7199-94e911d9b68b@shipmail.org> <805c49b7-f0b3-45dc-5fe3-b352f0971527@shipmail.org> <92393d26-d863-aac6-6d27-53cad6854e13@shipmail.org> <8fd999f2-cbf6-813c-6ad4-131948fb5cc5@shipmail.org> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= Message-ID: <697d1b5e-5d1c-1655-23f8-7a3f652606f3@shipmail.org> Date: Wed, 22 Jul 2020 15:12:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Felix Kuehling , Daniel Stone , linux-rdma , Intel Graphics Development , Maarten Lankhorst , DRI Development , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Steve Pronovost , amd-gfx mailing list , Jason Ekstrand , Jesse Natalie , Daniel Vetter , Thomas Hellstrom , Linux Media Mailing List , Dave Airlie , =?UTF-8?Q?Christian_K=c3=b6nig?= , Mika Kuoppala Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On 2020-07-22 14:41, Daniel Vetter wrote: > > Ah I think I misunderstood which options you want to compare here. I'm > not sure how much pain fixing up "dma-fence as memory fence" really > is. That's kinda why I want a lot more testing on my annotation > patches, to figure that out. Not much feedback aside from amdgpu and > intel, and those two drivers pretty much need to sort out their memory > fence issues anyway (because of userptr and stuff like that). > > The only other issues outside of these two drivers I'm aware of: > - various scheduler drivers doing allocations in the drm/scheduler > critical section. Since all arm-soc drivers have a mildly shoddy > memory model of "we just pin everything" they don't really have to > deal with this. So we might just declare arm as a platform broken and > not taint the dma-fence critical sections with fs_reclaim. Otoh we > need to fix this for drm/scheduler anyway, I think best option would > be to have a mempool for hw fences in the scheduler itself, and at > that point fixing the other drivers shouldn't be too onerous. > > - vmwgfx doing a dma_resv in the atomic commit tail. Entirely > orthogonal to the entire memory fence discussion. With vmwgfx there is another issue that is hit when the gpu signals an error. At that point the batch might be restarted with a new meta command buffer that needs to be allocated out of a dma pool. in the fence critical section. That's probably a bit nasty to fix, but not impossible. > > I'm pretty sure there's more bugs, I just haven't heard from them yet. > Also due to the opt-in nature of dma-fence we can limit the scope of > what we fix fairly naturally, just don't put them where no one cares > :-) Of course that also hides general locking issues in dma_fence > signalling code, but well *shrug*. Hmm, yes. Another potential big problem would be drivers that want to use gpu page faults in the dma-fence critical sections with the batch-based programming model. /Thomas _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx