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 3CCFBC433FE for ; Tue, 4 Oct 2022 14:09:01 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B0FBF10E5F8; Tue, 4 Oct 2022 14:08:59 +0000 (UTC) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id E1AD510E5F8; Tue, 4 Oct 2022 14:08: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=1664892537; x=1696428537; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=NufrIMXEyh/krbXboFFo1zeD2uhg5pv6DFpqUnd2GUo=; b=VxymmV9CnYLgmeumx51mqksYkpoJUFMWkTIE/zTNhOK9Q5s4R15TK3Ls NmHrctPPkVzSaAeI+/nAyIy2dudABmHhRYYgjsBH5gD1D6tVSd/5wSCiJ UJuUFZ0zjg+pfB5LWV0Oqo49i7N+hMFjkxvGIsevI7Hzx2XILNjtpG6d0 NjTRWydJ63CUUB9ea2zVq4Nw5VWo9kAz6VdFSc9ykCpDAroYgBNy9sXlE VzUjjXtIpA6AXqvU3c4xrMgQNBEKKtEMVF/TBTZqGJ/qJ35O/OgKLehXy Zj1T1kXLNEApqYrusn7rX2VaBAdc12HHmwMilfQp0jCgpa6r+aD1OtpwK g==; X-IronPort-AV: E=McAfee;i="6500,9779,10490"; a="286107391" X-IronPort-AV: E=Sophos;i="5.95,158,1661842800"; d="scan'208";a="286107391" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2022 07:08:39 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10490"; a="601632603" X-IronPort-AV: E=Sophos;i="5.95,158,1661842800"; d="scan'208";a="601632603" Received: from nirmoyda-mobl.ger.corp.intel.com (HELO [10.252.22.232]) ([10.252.22.232]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2022 07:08:35 -0700 Message-ID: Date: Tue, 4 Oct 2022 16:08:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v3 2/2] drm/i915/uapi: expose GTT alignment Content-Language: en-US To: Matthew Auld , intel-gfx@lists.freedesktop.org References: <20221004114915.221708-1-matthew.auld@intel.com> <20221004114915.221708-2-matthew.auld@intel.com> From: "Das, Nirmoy" In-Reply-To: <20221004114915.221708-2-matthew.auld@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= , Yang A Shi , Jordan Justen , Lionel Landwerlin , Stuart Summers , Michal Mrozek , dri-devel@lists.freedesktop.org, Niranjana Vishwanathapura , Nirmoy Das Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 10/4/2022 1:49 PM, Matthew Auld wrote: > On some platforms we potentially have different alignment restrictions > depending on the memory type. We also now have different alignment > restrictions for the same region across different kernel versions. > Extend the region query to return the minimum required GTT alignment. > > Testcase: igt@gem_create@create-ext-placement-alignment > Testcase: igt@i915_query@query-regions-sanity-check > Suggested-by: Lionel Landwerlin > Signed-off-by: Matthew Auld > Cc: Michal Mrozek > Cc: Thomas Hellström > Cc: Stuart Summers > Cc: Jordan Justen > Cc: Yang A Shi > Cc: Nirmoy Das Reviewed-by: Nirmoy Das > Cc: Niranjana Vishwanathapura > --- > drivers/gpu/drm/i915/i915_query.c | 1 + > include/uapi/drm/i915_drm.h | 29 +++++++++++++++++++++++++++-- > 2 files changed, 28 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c > index 6ec9c9fb7b0d..111377f210ed 100644 > --- a/drivers/gpu/drm/i915/i915_query.c > +++ b/drivers/gpu/drm/i915/i915_query.c > @@ -498,6 +498,7 @@ static int query_memregion_info(struct drm_i915_private *i915, > info.region.memory_class = mr->type; > info.region.memory_instance = mr->instance; > info.probed_size = mr->total; > + info.gtt_alignment = mr->min_page_size; > > if (mr->type == INTEL_MEMORY_LOCAL) > info.probed_cpu_visible_size = mr->io_size; > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index 08d69e36fb66..2e613109356b 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -3346,8 +3346,33 @@ struct drm_i915_memory_region_info { > /** @region: The class:instance pair encoding */ > struct drm_i915_gem_memory_class_instance region; > > - /** @rsvd0: MBZ */ > - __u32 rsvd0; > + union { > + /** @rsvd0: MBZ */ > + __u32 rsvd0; > + /** > + * @gtt_alignment: > + * > + * The minimum required GTT alignment for this type of memory. > + * When allocating a GTT address it must be aligned to this > + * value or larger. On some platforms the kernel might opt to > + * using 64K pages for I915_MEMORY_CLASS_DEVICE, where 64K GTT > + * pages can then be used if we also use 64K GTT alignment. > + * > + * NOTE: If this is zero then this must be an older > + * kernel which lacks support for this field. > + * > + * Side note: For larger objects (especially for > + * I915_MEMORY_CLASS_DEVICE), like 2M+ in size, userspace should > + * consider potentially bumping the GTT alignment to say 2M, > + * which could potentially increase the likelihood of the kernel > + * being able to utilise 2M GTT pages underneath, if the layout > + * of the physical pages allows it. On some configurations we > + * can then also use a more efficient page-table layout, if we > + * can't use the more desirable 2M GTT page, so long as we know > + * that the entire page-table will be used by this object. > + */ > + __u32 gtt_alignment; > + }; > > /** > * @probed_size: Memory probed by the driver 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 09F3FC433FE for ; Tue, 4 Oct 2022 14:09:08 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2BEA710E613; Tue, 4 Oct 2022 14:09:00 +0000 (UTC) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id E1AD510E5F8; Tue, 4 Oct 2022 14:08: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=1664892537; x=1696428537; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=NufrIMXEyh/krbXboFFo1zeD2uhg5pv6DFpqUnd2GUo=; b=VxymmV9CnYLgmeumx51mqksYkpoJUFMWkTIE/zTNhOK9Q5s4R15TK3Ls NmHrctPPkVzSaAeI+/nAyIy2dudABmHhRYYgjsBH5gD1D6tVSd/5wSCiJ UJuUFZ0zjg+pfB5LWV0Oqo49i7N+hMFjkxvGIsevI7Hzx2XILNjtpG6d0 NjTRWydJ63CUUB9ea2zVq4Nw5VWo9kAz6VdFSc9ykCpDAroYgBNy9sXlE VzUjjXtIpA6AXqvU3c4xrMgQNBEKKtEMVF/TBTZqGJ/qJ35O/OgKLehXy Zj1T1kXLNEApqYrusn7rX2VaBAdc12HHmwMilfQp0jCgpa6r+aD1OtpwK g==; X-IronPort-AV: E=McAfee;i="6500,9779,10490"; a="286107391" X-IronPort-AV: E=Sophos;i="5.95,158,1661842800"; d="scan'208";a="286107391" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2022 07:08:39 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10490"; a="601632603" X-IronPort-AV: E=Sophos;i="5.95,158,1661842800"; d="scan'208";a="601632603" Received: from nirmoyda-mobl.ger.corp.intel.com (HELO [10.252.22.232]) ([10.252.22.232]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2022 07:08:35 -0700 Message-ID: Date: Tue, 4 Oct 2022 16:08:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: en-US To: Matthew Auld , intel-gfx@lists.freedesktop.org References: <20221004114915.221708-1-matthew.auld@intel.com> <20221004114915.221708-2-matthew.auld@intel.com> From: "Das, Nirmoy" In-Reply-To: <20221004114915.221708-2-matthew.auld@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/uapi: expose GTT alignment 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: =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= , Michal Mrozek , dri-devel@lists.freedesktop.org, Nirmoy Das Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 10/4/2022 1:49 PM, Matthew Auld wrote: > On some platforms we potentially have different alignment restrictions > depending on the memory type. We also now have different alignment > restrictions for the same region across different kernel versions. > Extend the region query to return the minimum required GTT alignment. > > Testcase: igt@gem_create@create-ext-placement-alignment > Testcase: igt@i915_query@query-regions-sanity-check > Suggested-by: Lionel Landwerlin > Signed-off-by: Matthew Auld > Cc: Michal Mrozek > Cc: Thomas Hellström > Cc: Stuart Summers > Cc: Jordan Justen > Cc: Yang A Shi > Cc: Nirmoy Das Reviewed-by: Nirmoy Das > Cc: Niranjana Vishwanathapura > --- > drivers/gpu/drm/i915/i915_query.c | 1 + > include/uapi/drm/i915_drm.h | 29 +++++++++++++++++++++++++++-- > 2 files changed, 28 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c > index 6ec9c9fb7b0d..111377f210ed 100644 > --- a/drivers/gpu/drm/i915/i915_query.c > +++ b/drivers/gpu/drm/i915/i915_query.c > @@ -498,6 +498,7 @@ static int query_memregion_info(struct drm_i915_private *i915, > info.region.memory_class = mr->type; > info.region.memory_instance = mr->instance; > info.probed_size = mr->total; > + info.gtt_alignment = mr->min_page_size; > > if (mr->type == INTEL_MEMORY_LOCAL) > info.probed_cpu_visible_size = mr->io_size; > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index 08d69e36fb66..2e613109356b 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -3346,8 +3346,33 @@ struct drm_i915_memory_region_info { > /** @region: The class:instance pair encoding */ > struct drm_i915_gem_memory_class_instance region; > > - /** @rsvd0: MBZ */ > - __u32 rsvd0; > + union { > + /** @rsvd0: MBZ */ > + __u32 rsvd0; > + /** > + * @gtt_alignment: > + * > + * The minimum required GTT alignment for this type of memory. > + * When allocating a GTT address it must be aligned to this > + * value or larger. On some platforms the kernel might opt to > + * using 64K pages for I915_MEMORY_CLASS_DEVICE, where 64K GTT > + * pages can then be used if we also use 64K GTT alignment. > + * > + * NOTE: If this is zero then this must be an older > + * kernel which lacks support for this field. > + * > + * Side note: For larger objects (especially for > + * I915_MEMORY_CLASS_DEVICE), like 2M+ in size, userspace should > + * consider potentially bumping the GTT alignment to say 2M, > + * which could potentially increase the likelihood of the kernel > + * being able to utilise 2M GTT pages underneath, if the layout > + * of the physical pages allows it. On some configurations we > + * can then also use a more efficient page-table layout, if we > + * can't use the more desirable 2M GTT page, so long as we know > + * that the entire page-table will be used by this object. > + */ > + __u32 gtt_alignment; > + }; > > /** > * @probed_size: Memory probed by the driver