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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 078D5C433EF for ; Mon, 21 Mar 2022 13:41:02 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 51FE110E350; Mon, 21 Mar 2022 13:40:58 +0000 (UTC) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0AEA310E346; Mon, 21 Mar 2022 13:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647870057; x=1679406057; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=eAtpi4PDlrO7uimuy/Kh+72hIkzBKxOKO/7IV9U7P4A=; b=KxtAI3s8YiSnkCWq7AEwn5hUdzC8H6tUCMAeqXt7pd9eTp6FS8qN6k5m n08xqYR1WB5A9ET3ZWsqeZ5TFsVioZTDKkxNuy1+kz+Jar9AYQP75kCDW J54SnLfxbGRiizOCzxZcAGc+3lPczTrmxy5LYuAIECEZTv+OrK9UIqh/R +ExGJu00oEMJu4jhGcPooRz+m26dviSylR9Uc5hPcL4XaPJOJPFN7eKB+ m3jK668gMIv4537PhYhW5CFyrVTi8hGBKC9qU7z1aT1mTNiRwi+zeDGTx U2Lo9HjZT/nTDn5hJq+tK2WTpCmtIj535tgUIUErPDn6a67LV8KgJtBcl Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10292"; a="257744498" X-IronPort-AV: E=Sophos;i="5.90,198,1643702400"; d="scan'208";a="257744498" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Mar 2022 06:40:56 -0700 X-IronPort-AV: E=Sophos;i="5.90,198,1643702400"; d="scan'208";a="648567928" Received: from evinintel.ger.corp.intel.com (HELO [10.249.254.209]) ([10.249.254.209]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Mar 2022 06:40:53 -0700 Message-ID: <1bd4ac91f24f6b4322811177f786f4867278ab83.camel@linux.intel.com> From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Tvrtko Ursulin , Michael Cheng , intel-gfx@lists.freedesktop.org Date: Mon, 21 Mar 2022 14:40:51 +0100 In-Reply-To: <210af2db-37ec-2cff-f6a6-7ea0263e135b@linux.intel.com> References: <20220319194227.297639-1-michael.cheng@intel.com> <4c86ae70-6f97-7a7c-1fd4-5e73ca29d0ba@linux.intel.com> <5db61477-6064-ada0-82a7-c1dc659dacad@linux.intel.com> <29bde7b0e680e503fbf483a560616e2ce22cdd79.camel@linux.intel.com> <210af2db-37ec-2cff-f6a6-7ea0263e135b@linux.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [Intel-gfx] [PATCH 0/4] Drop wbinvd_on_all_cpus usage 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: daniel.vetter@ffwll.ch, lucas.demarchi@intel.com, dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk, Matthew Auld Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Hi, On Mon, 2022-03-21 at 13:12 +0000, Tvrtko Ursulin wrote: > > On 21/03/2022 12:33, Thomas Hellström wrote: > > On Mon, 2022-03-21 at 12:22 +0000, Tvrtko Ursulin wrote: > > > > > > On 21/03/2022 11:03, Thomas Hellström wrote: > > > > Hi, Tvrtko. > > > > > > > > On 3/21/22 11:27, Tvrtko Ursulin wrote: > > > > > > > > > > On 19/03/2022 19:42, Michael Cheng wrote: > > > > > > To align with the discussion in [1][2], this patch series > > > > > > drops > > > > > > all > > > > > > usage of > > > > > > wbvind_on_all_cpus within i915 by either replacing the call > > > > > > with certain > > > > > > drm clflush helpers, or reverting to a previous logic. > > > > > > > > > > AFAIU, complaint from [1] was that it is wrong to provide non > > > > > x86 > > > > > implementations under the wbinvd_on_all_cpus name. Instead an > > > > > arch > > > > > agnostic helper which achieves the same effect could be > > > > > created. > > > > > Does > > > > > Arm have such concept? > > > > > > > > I also understand Linus' email like we shouldn't leak incoherent > > > > IO > > > > to > > > > other architectures, meaning any remaining wbinvd()s should be > > > > X86 > > > > only. > > > > > > The last part is completely obvious since it is a x86 instruction > > > name. > > > > Yeah, I meant the function implementing wbinvd() semantics. > > > > > > > > But I think we can't pick a solution until we know how the concept > > > maps > > > to Arm and that will also include seeing how the drm_clflush_sg for > > > Arm > > > would look. Is there a range based solution, or just a big hammer > > > there. > > > If the latter, then it is no good to churn all these reverts but > > > instead > > > an arch agnostic wrapper, with a generic name, would be the way to > > > go. > > > > But my impression was that ARM would not need the range-based > > interface > > either, because ARM is only for discrete and with discrete we're > > always > > coherent. > > Not sure what you mean here - what about flushing system memory objects > on discrete? Those still need flushing on paths like suspend which this > series touches. Am I missing something? System bos on discrete should always have I915_BO_CACHE_COHERENT_FOR_READ | I915_BO_CACHE_COHERENT_FOR_WRITE either by the gpu being fully cache coherent (or us mapping system write-combined). Hence no need for cache clflushes or wbinvd() for incoherent IO. That's adhering to Linus' "And I sincerely hope to the gods that no cache-incoherent i915 mess ever makes it out of the x86 world. Incoherent IO was always a historical mistake and should never ever happen again, so we should not spread that horrific pattern around." /Thomas