From patchwork Tue Feb 7 09:22:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Wang, Zhi A" X-Patchwork-Id: 9559621 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1A76960236 for ; Tue, 7 Feb 2017 09:32:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 073DA28285 for ; Tue, 7 Feb 2017 09:32:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EFFB428334; Tue, 7 Feb 2017 09:32:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 954D028285 for ; Tue, 7 Feb 2017 09:32:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CA8456E61F; Tue, 7 Feb 2017 09:32:26 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 957EE6E61F for ; Tue, 7 Feb 2017 09:32:25 +0000 (UTC) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP; 07 Feb 2017 01:32:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,345,1477983600"; d="scan'208";a="62760046" Received: from dev-inno.bj.intel.com (HELO [10.238.135.53]) ([10.238.135.53]) by fmsmga006.fm.intel.com with ESMTP; 07 Feb 2017 01:32:23 -0800 Message-ID: <589991D9.9040609@intel.com> Date: Tue, 07 Feb 2017 17:22:33 +0800 From: Zhi Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Chris Wilson , intel-gfx@lists.freedesktop.org, Tvrtko Ursulin , Michal Winiarski , Michel Thierry , Joonas Lahtinen , Zhenyu Wang , Zhiyuan Lv References: <1486377436-15380-1-git-send-email-zhi.a.wang@intel.com> <20170206105824.GC12434@nuc-i3427.alporthouse.com> <5898580B.8000001@intel.com> <20170206113820.GG12434@nuc-i3427.alporthouse.com> In-Reply-To: <20170206113820.GG12434@nuc-i3427.alporthouse.com> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Let execlist_update_context() cover !FULL_PPGTT mode. X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP Hi Chris: Thanks for the explanation! :P Have you already sent the patch to keep PD structure under aliasing PPGTT mode? I tried drm-intel-nightly branch and still got kernel panic under aliasing PPGTT mode. T_T I fixed it like this, is this acceptable as a hot fix? If it's acceptable as a hot fix, I can send a patch. :P intel_runtime_pm_get(i915); @@ -2666,14 +2679,6 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma, cache_level, pte_flags); intel_runtime_pm_put(i915); } - - if (flags & I915_VMA_LOCAL_BIND) { - struct i915_hw_ppgtt *appgtt = i915->mm.aliasing_ppgtt; - appgtt->base.insert_entries(&appgtt->base, - vma->pages, vma->node.start, - cache_level, pte_flags); - } - return 0; } On 02/06/17 19:38, Chris Wilson wrote: > On Mon, Feb 06, 2017 at 07:03:39PM +0800, Zhi Wang wrote: >> Thanks for the merging. I guess that with your patches of keeping PD >> structure under aliasing PPGTT mode in 32bit page table, the amount >> of PDPs will not change anymore under aliasing PPGTT mode. :P > > Yes. That's the idea atm, we will preallocate the aliasing table > and then keep the tree intact. The only disadvantage with gen8+ aliasing > mode (compared to gen6) will be that we still have to walk the va range > to pin the tree so that when we call clear_range afterwards we don't > reap. The benefit from my pov, is that the special case for > aliasing_ppgtt is within the aliasing_ppgtt code and not in the common > code (which should be optimised for full-ppgtt as that is the > default/typical use). > -Chris > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 22b3374..21e06c9 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -2658,6 +2658,19 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma, if (vma->obj->gt_ro) pte_flags |= PTE_READ_ONLY; + if (flags & I915_VMA_LOCAL_BIND) { + struct i915_hw_ppgtt *appgtt = i915->mm.aliasing_ppgtt; + + ret = appgtt->base.allocate_va_range(&appgtt->base, + vma->node.start, + vma->node.size); + if (ret) + return ret; + + appgtt->base.insert_entries(&appgtt->base, + vma->pages, vma->node.start, + cache_level, pte_flags); + } if (flags & I915_VMA_GLOBAL_BIND) {