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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 69E88C433E2 for ; Thu, 17 Sep 2020 10:38:41 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 D600C2087D for ; Thu, 17 Sep 2020 10:38:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D600C2087D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 5A969875B9; Thu, 17 Sep 2020 10:38:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvcYJ9YKSKrG; Thu, 17 Sep 2020 10:38:38 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by whitealder.osuosl.org (Postfix) with ESMTP id 73CDD8756D; Thu, 17 Sep 2020 10:38:38 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5BBFDC0864; Thu, 17 Sep 2020 10:38:38 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D3DBAC0051 for ; Thu, 17 Sep 2020 10:38:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id CFBFA875E2 for ; Thu, 17 Sep 2020 10:38:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUY1L1AP3xqE for ; Thu, 17 Sep 2020 10:38:35 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by hemlock.osuosl.org (Postfix) with ESMTP id D53FE875DD for ; Thu, 17 Sep 2020 10:38:35 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ED87B30E; Thu, 17 Sep 2020 03:38:34 -0700 (PDT) Received: from [192.168.1.79] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 995B73F68F; Thu, 17 Sep 2020 03:38:32 -0700 (PDT) Subject: Re: [PATCH 0/3] drm: panfrost: Coherency support To: Rob Herring , Alyssa Rosenzweig References: <20200916170409.GA2543@kevin> From: Steven Price Message-ID: Date: Thu, 17 Sep 2020 11:38:31 +0100 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-GB Cc: Tomeu Vizoso , Neil Armstrong , Robin Murphy , dri-devel , Linux IOMMU , Kevin Hilman , "open list:ARM/Amlogic Meson..." , Will Deacon , linux-arm-kernel , Jerome Brunet X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 16/09/2020 18:46, Rob Herring wrote: > On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig > wrote: >> >>> So I get a performance regression with the dma-coherent approach, even if it's >>> clearly the cleaner. >> >> That's bizarre -- this should really be the faster of the two. > > Coherency may not be free. CortexA9 had something like 4x slower > memcpy if SMP was enabled as an example. I don't know if there's > anything going on like that specifically here. If there's never any > CPU accesses mixed in with kmscube, then there would be no benefit to > coherency. The DDK blob has the ability to mark only certain areas of memory as coherent for performance reasons. For simple things like kmscube I would expect that it's basically write-only from the CPU and almost all memory the GPU touches isn't touched by the CPU. I.e. coherency isn't helping and the coherency traffic is probably expensive. Whether the complexity is worth it for "real" content I don't know - it may just be silly benchmarks that benefit. Steve _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 06C4EC43461 for ; Thu, 17 Sep 2020 10:39:52 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 75EA52087D for ; Thu, 17 Sep 2020 10:39:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Slgis8Kj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 75EA52087D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lwvd2tkZgfYG0rkUXSA6rBp6WEn1QdsFguUHMYtAKb4=; b=Slgis8Kjt91xo9MPEKVwQHXoC aE8l1FnNqv4FiCP1b0t3bfu8iRMvdbmtk1BTemgCRl99CU7Ba6wwsryjAjVaVAnuTYJE25tjLyr/O H2R1H45CZ/kv1/IdXCnWVFXcSwS05eILEgVkETp/fc6zg882eHFDveUlE7e2Tf4n+StOGuIm7zRkP oONPvkxKnKLSq4hYRMdk8XbyBwPOBmubaKZpoKxDAbf9u2A6nEu8y/PKkI0dRAwDmq6IyIfDo1StF snRaioHG1Fan/N+6cl5Gr/1D+P0v11E9KhqRy5gx81LpIIQsi6HNver6Vy7/OqX8fZK0Hct/515qY la969ZQFA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIrJI-0008W5-07; Thu, 17 Sep 2020 10:38:40 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIrJE-0008V2-8n; Thu, 17 Sep 2020 10:38:37 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ED87B30E; Thu, 17 Sep 2020 03:38:34 -0700 (PDT) Received: from [192.168.1.79] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 995B73F68F; Thu, 17 Sep 2020 03:38:32 -0700 (PDT) Subject: Re: [PATCH 0/3] drm: panfrost: Coherency support To: Rob Herring , Alyssa Rosenzweig References: <20200916170409.GA2543@kevin> From: Steven Price Message-ID: Date: Thu, 17 Sep 2020 11:38:31 +0100 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-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200917_063836_377988_3656C49E X-CRM114-Status: GOOD ( 16.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tomeu Vizoso , Neil Armstrong , Robin Murphy , dri-devel , Linux IOMMU , Kevin Hilman , "open list:ARM/Amlogic Meson..." , Will Deacon , linux-arm-kernel , Jerome Brunet Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 16/09/2020 18:46, Rob Herring wrote: > On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig > wrote: >> >>> So I get a performance regression with the dma-coherent approach, even if it's >>> clearly the cleaner. >> >> That's bizarre -- this should really be the faster of the two. > > Coherency may not be free. CortexA9 had something like 4x slower > memcpy if SMP was enabled as an example. I don't know if there's > anything going on like that specifically here. If there's never any > CPU accesses mixed in with kmscube, then there would be no benefit to > coherency. The DDK blob has the ability to mark only certain areas of memory as coherent for performance reasons. For simple things like kmscube I would expect that it's basically write-only from the CPU and almost all memory the GPU touches isn't touched by the CPU. I.e. coherency isn't helping and the coherency traffic is probably expensive. Whether the complexity is worth it for "real" content I don't know - it may just be silly benchmarks that benefit. Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 13175C43461 for ; Thu, 17 Sep 2020 10:38:38 +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 8ADAC2072E for ; Thu, 17 Sep 2020 10:38:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8ADAC2072E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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 C7FE86E132; Thu, 17 Sep 2020 10:38:36 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 442926E132 for ; Thu, 17 Sep 2020 10:38:35 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ED87B30E; Thu, 17 Sep 2020 03:38:34 -0700 (PDT) Received: from [192.168.1.79] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 995B73F68F; Thu, 17 Sep 2020 03:38:32 -0700 (PDT) Subject: Re: [PATCH 0/3] drm: panfrost: Coherency support To: Rob Herring , Alyssa Rosenzweig References: <20200916170409.GA2543@kevin> From: Steven Price Message-ID: Date: Thu, 17 Sep 2020 11:38:31 +0100 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-GB 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: Tomeu Vizoso , Neil Armstrong , Robin Murphy , dri-devel , Linux IOMMU , Kevin Hilman , "open list:ARM/Amlogic Meson..." , Will Deacon , linux-arm-kernel , Jerome Brunet 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 16/09/2020 18:46, Rob Herring wrote: > On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig > wrote: >> >>> So I get a performance regression with the dma-coherent approach, even if it's >>> clearly the cleaner. >> >> That's bizarre -- this should really be the faster of the two. > > Coherency may not be free. CortexA9 had something like 4x slower > memcpy if SMP was enabled as an example. I don't know if there's > anything going on like that specifically here. If there's never any > CPU accesses mixed in with kmscube, then there would be no benefit to > coherency. The DDK blob has the ability to mark only certain areas of memory as coherent for performance reasons. For simple things like kmscube I would expect that it's basically write-only from the CPU and almost all memory the GPU touches isn't touched by the CPU. I.e. coherency isn't helping and the coherency traffic is probably expensive. Whether the complexity is worth it for "real" content I don't know - it may just be silly benchmarks that benefit. Steve _______________________________________________ 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=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 10756C43461 for ; Thu, 17 Sep 2020 10:38:45 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 880D22087D for ; Thu, 17 Sep 2020 10:38:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="dBU2uTxJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 880D22087D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6/IKPGOkbEzFnaMtTHiOBQUjo/Ug4ZmJIteL7hYw7WA=; b=dBU2uTxJ846CjkqDsVprINJOP PzUohFkAvs0QzvRkQZ81sCcxDRhJtQfkiX7EZ0EflQuBb/Lzrg7e8WprmOCEunHuKgXKFZYJvYguW mhb0HVXkJess83gF91pDT3e9erlyx6zO1Yckbnly38SDIpWAX7DlGOx6kmeeehPS31CkIU96RkuOd oZKQJTP5whsytMGlFHWvKnZdosy4hd1DAEwJaT7NyxOedzk6EPR6xZUavJ5dyukprFKEbl8Om82jy IREkN/8ma9zFwGb3ohYlNFAP86N364Ck5edVkY2kBXauMBwoG5xIXP0XgYx2r0QPgl8GpuH2b8JSz mMFPs8vsA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIrJG-0008Vb-NI; Thu, 17 Sep 2020 10:38:38 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIrJE-0008V2-8n; Thu, 17 Sep 2020 10:38:37 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ED87B30E; Thu, 17 Sep 2020 03:38:34 -0700 (PDT) Received: from [192.168.1.79] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 995B73F68F; Thu, 17 Sep 2020 03:38:32 -0700 (PDT) Subject: Re: [PATCH 0/3] drm: panfrost: Coherency support To: Rob Herring , Alyssa Rosenzweig References: <20200916170409.GA2543@kevin> From: Steven Price Message-ID: Date: Thu, 17 Sep 2020 11:38:31 +0100 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-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200917_063836_377988_3656C49E X-CRM114-Status: GOOD ( 16.51 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tomeu Vizoso , Neil Armstrong , Robin Murphy , dri-devel , Linux IOMMU , Kevin Hilman , "open list:ARM/Amlogic Meson..." , Will Deacon , linux-arm-kernel , Jerome Brunet Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org On 16/09/2020 18:46, Rob Herring wrote: > On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig > wrote: >> >>> So I get a performance regression with the dma-coherent approach, even if it's >>> clearly the cleaner. >> >> That's bizarre -- this should really be the faster of the two. > > Coherency may not be free. CortexA9 had something like 4x slower > memcpy if SMP was enabled as an example. I don't know if there's > anything going on like that specifically here. If there's never any > CPU accesses mixed in with kmscube, then there would be no benefit to > coherency. The DDK blob has the ability to mark only certain areas of memory as coherent for performance reasons. For simple things like kmscube I would expect that it's basically write-only from the CPU and almost all memory the GPU touches isn't touched by the CPU. I.e. coherency isn't helping and the coherency traffic is probably expensive. Whether the complexity is worth it for "real" content I don't know - it may just be silly benchmarks that benefit. Steve _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic