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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 A9C37C433DB for ; Mon, 18 Jan 2021 14:54:39 +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 CE8C322C7E for ; Mon, 18 Jan 2021 14:54:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE8C322C7E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk 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 660F26E2C7; Mon, 18 Jan 2021 14:54:37 +0000 (UTC) Received: from fireflyinternet.com (unknown [77.68.26.236]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1A6766E2C7 for ; Mon, 18 Jan 2021 14:54:35 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 23629964-1500050 for multiple; Mon, 18 Jan 2021 14:54:33 +0000 MIME-Version: 1.0 In-Reply-To: <20210118141732.90173-2-matthew.auld@intel.com> References: <20210118141732.90173-1-matthew.auld@intel.com> <20210118141732.90173-2-matthew.auld@intel.com> From: Chris Wilson To: Matthew Auld , intel-gfx@lists.freedesktop.org Date: Mon, 18 Jan 2021 14:54:32 +0000 Message-ID: <161098167206.301.604373583078584678@build.alporthouse.com> User-Agent: alot/0.9 Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: prefer FORCE_WC for the blitter routines 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Quoting Matthew Auld (2021-01-18 14:17:31) > From: CQ Tang > > The pool is shared and so we might find that there is a pool object with > an existing mapping, but is mapped with different underlying type, which > will result in -EBUSY. > > Signed-off-by: CQ Tang > Signed-off-by: Matthew Auld > --- > drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c > index 10cac9fac79b..c6db745900b3 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c > @@ -55,7 +55,7 @@ struct i915_vma *intel_emit_vma_fill_blt(struct intel_context *ce, > if (unlikely(err)) > goto out_put; > > - cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_WC); > + cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WC); > if (IS_ERR(cmd)) { > err = PTR_ERR(cmd); > goto out_unpin; > @@ -277,7 +277,7 @@ struct i915_vma *intel_emit_vma_copy_blt(struct intel_context *ce, > if (unlikely(err)) > goto out_put; > > - cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_WC); > + cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WC); > if (IS_ERR(cmd)) { > err = PTR_ERR(cmd); > goto out_unpin; FORCE is becoming meaningless. In this case we pin the pages upon acquiring from the pool, which then prevents us from changing the mapping type. The purpose of which was so that we could cache the mapping between users, and here we are saying that cache is made useless. The danger is that we are now thrashing the cache, hurting ourselves with the vmap overhead. Maybe we should move the mapping-type into the buffer-pool cache itself? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx