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=-14.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,INCLUDES_CR_TRAILER, INCLUDES_PATCH,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 B9126C433DB for ; Fri, 12 Mar 2021 11:47:46 +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 5B70164EE8 for ; Fri, 12 Mar 2021 11:47:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5B70164EE8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com 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 02E856F5CC; Fri, 12 Mar 2021 11:47:46 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3764D6F5CB for ; Fri, 12 Mar 2021 11:47:44 +0000 (UTC) IronPort-SDR: MdMNoIdKW8Y+kEvgzpv7s2CBBVEFOolIMlc0yAVAdMGdrRPpucWNV5mJvC4v8qTZmLARkjCH5T W/1a4ao60ZdQ== X-IronPort-AV: E=McAfee;i="6000,8403,9920"; a="168737459" X-IronPort-AV: E=Sophos;i="5.81,243,1610438400"; d="scan'208";a="168737459" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2021 03:47:42 -0800 IronPort-SDR: PYmCl7eJrlNX/VFziWLuli34Od1uypyPhqp7kNp25R/tJJbPLNymOlHMcdjl3XgYoY7KKXM8eF +Bc7GfplhBbw== X-IronPort-AV: E=Sophos;i="5.81,243,1610438400"; d="scan'208";a="448602294" Received: from nstrumtz-desk02.ger.corp.intel.com (HELO [10.214.213.111]) ([10.214.213.111]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2021 03:47:40 -0800 To: Matthew Auld References: <20210310215007.782649-1-jason@jlekstrand.net> <20210311181733.1048640-1-jason@jlekstrand.net> <39bfc60f-cc5a-d793-5cea-e1b8e0751d62@linux.intel.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: <25050bac-d576-bfdc-b318-21bcc8afd6f8@linux.intel.com> Date: Fri, 12 Mar 2021 11:47:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Subject: Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4) 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: Dave Airlie , Intel Graphics Development , Daniel Vetter 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 12/03/2021 10:56, Matthew Auld wrote: > On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin > wrote: >> >> >> On 11/03/2021 18:17, Jason Ekstrand wrote: >>> The Vulkan driver in Mesa for Intel hardware never uses relocations if >>> it's running on a version of i915 that supports at least softpin which >>> all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is >>> only supported by iris which never uses relocations. The older i965 >>> driver in Mesa does use relocations but it only supports Intel hardware >>> through Gen11 and has been deprecated for all hardware Gen9+. The >>> compute driver also never uses relocations. This only leaves the media >>> driver which is supposed to be switching to softpin going forward. >>> Making softpin a requirement for all future hardware seems reasonable. >>> >>> There is one piece of hardware enabled by default in i915: RKL which was >>> enabled by e22fa6f0a976 which has not yet landed in drm-next so this >>> almost but not really a userspace API change for RKL. If it becomes a >>> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition. >>> >>> Rejecting relocations starting with newer Gen12 platforms has the >>> benefit that we don't have to bother supporting it on platforms with >>> local memory. Given how much CPU touching of memory is required for >>> relocations, not having to do so on platforms where not all memory is >>> directly CPU-accessible carries significant advantages. >>> >>> v2 (Jason Ekstrand): >>> - Allow TGL-LP platforms as they've already shipped >>> >>> v3 (Jason Ekstrand): >>> - WARN_ON platforms with LMEM support in case the check is wrong >>> >>> v4 (Jason Ekstrand): >>> - Call out Rocket Lake in the commit message >>> >>> Signed-off-by: Jason Ekstrand >>> Acked-by: Keith Packard >>> Cc: Dave Airlie >>> Cc: Daniel Vetter >>> --- >>> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++--- >>> 1 file changed, 12 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c >>> index 99772f37bff60..b02dbd16bfa03 100644 >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c >>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev) >>> return err; >>> } >>> >>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry) >>> +static int check_relocations(const struct i915_execbuffer *eb, >>> + const struct drm_i915_gem_exec_object2 *entry) >>> { >>> const char __user *addr, *end; >>> unsigned long size; >>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry) >>> if (size == 0) >>> return 0; >>> >>> + /* Relocations are disallowed for all platforms after TGL-LP */ >>> + if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915)) >>> + return -EINVAL; >> >> I still recommend ENODEV as more inline with our established error >> codes. (Platform does not support vs dear userspace you messed up your >> flags, modes, whatever.) >> >>> + >>> + /* All discrete memory platforms are Gen12 or above */ >>> + if (WARN_ON(HAS_LMEM(eb->i915))) >>> + return -EINVAL; >> >> What was the conclusion on value of supporting fake lmem? > >>>From the previous thread, nothing is currently using it, we did have a > dedicated machine in CI but that has been gone for some months it > seems, so it might already be broken. Also its use was limited only to > the live selftests, which can't even hit this path. The plan was to > eventually remove it, since supporting both real and fake lmem in the > same tree is likely more effort than it's worth. If I understand correctly you are saying it is safe to not have this check even if fake lmem is removed later? Presumably since there is no way to place an object into lmem in upstream from userspace, hence execbuf cannot use any? Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx