Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1266639pxb; Fri, 21 Jan 2022 13:51:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJxjqWGV8qOvJsKTbuThdZZmD/l95FvxR180KYcaDSA6oJbmrr+mfdPUvbtIh1CN+SxKhLlA X-Received: by 2002:a17:90b:3b91:: with SMTP id pc17mr346841pjb.193.1642801894338; Fri, 21 Jan 2022 13:51:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642801894; cv=none; d=google.com; s=arc-20160816; b=X8gEsv4nAXfmi+oNYTq4opw/lYLZ6JQrXYhMT7npWpoTQs+Ls/tRR3FlYRLwiXngxv yUzADdbFGjRDceO0LJAR5+JbQuY5i05Lqky5Zo3bK1XPFbO8vqwSMGF2AjzStsO/708R Okq+hA/UBzg0KejII0+6cu3kSkrP0274PYrT1SlaXPgHV2ih610VYPrvcKdV3T9yfOJ2 pMo8X/ex+c4d+nI7qrLT2YF/8GT7X1CbsVx4ISQ8RldBei7v4YfUvK0ICg5GK32gZiAP IOEBCu3dzO720J7WkhThFmRBx0kxbifLHsobsz6/A3CBbl4F3Ucf4yeWN93oMcpNyyNv QmOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=BopRCXo1gsBCmOa3mwmQ3UeGq/0RV/oFZyLwiKHvuP0=; b=Jd0BK73E6jRk4J2486ahYiwTbb/J0bKO19gnvimmKWQuNSV1PkHB4MTuT8NLIzkUmh EBXvakyL6P40tKlXjeGA9pqEYDK9G/PT4t+3UEgomEkK4dyKRNLqzL9QFDwSvHjwpJ8S Of+rSiw3Mo/XC5E9Lz8O70vcYl56AzgJNajCLuSWnXYbZNhJE2BhJahM5HrbcZhGlxJe W8bk+62sEtQYWUfHWXNNjm0ySFYLlrEdgm5p6l6YIOOmeceMbUZdc0T5hN+tkrPyiXEo +BL41Tzy6EiILCmIlxfFKwDwxUbZoWUu9ftajRYASVKQKZex7x5n4T/KChARZXgneS7+ hMDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Ksjkhc82; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h13si1742690plf.480.2022.01.21.13.51.22; Fri, 21 Jan 2022 13:51:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Ksjkhc82; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232172AbiATLyH (ORCPT + 99 others); Thu, 20 Jan 2022 06:54:07 -0500 Received: from mga06.intel.com ([134.134.136.31]:47456 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231604AbiATLyG (ORCPT ); Thu, 20 Jan 2022 06:54:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642679646; x=1674215646; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=hWH9CQcyJ3OyvK1GCGLRnCY5B+LN3QzOt6ywsVoqDPA=; b=Ksjkhc82EQmFEnBRIG95KJv+DXGgAslCX+u5picgjiN8c92U4cIuvLtM 61fks0TdEdNzeb1biZhK0FoBbn03iikAZsSPMTUewfYI6kPKbE2iErYJJ e5t4hsLegv4KcQ8w43CDRX0YrAP1goW+cI6KOzNDw620sOeHXEWts1eTd ttb3M/u/jjSRcY1UKuM1QNa0tTiBcMy0nCPVKfTP3nlAZpxCrv3M7xjfi KPLAADqoBbDTHNY6QgA5OPRyS5UMteh/1qF2cBiP82HYzrZ/xprreO4gQ yfeRtcqtlNTN4wWIdiOq8fGOyUhHYbPaqLTBo0TbhiuCi9mE+sc47i8bh g==; X-IronPort-AV: E=McAfee;i="6200,9189,10232"; a="306066367" X-IronPort-AV: E=Sophos;i="5.88,302,1635231600"; d="scan'208";a="306066367" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2022 03:54:06 -0800 X-IronPort-AV: E=Sophos;i="5.88,302,1635231600"; d="scan'208";a="767572817" Received: from ramaling-i9x.iind.intel.com (HELO intel.com) ([10.203.144.108]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2022 03:54:01 -0800 Date: Thu, 20 Jan 2022 17:23:58 +0530 From: Ramalingam C To: Robert Beckett Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , Simon Ser , Pekka Paalanen , Jordan Justen , Kenneth Graunke , mesa-dev@lists.freedesktop.org, Tony Ye , Slawomir Milczarek , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 4/4] drm/i915/uapi: document behaviour for DG2 64K support Message-ID: <20220120115357.GB8264@intel.com> References: <20220118175036.3840934-1-bob.beckett@collabora.com> <20220118175036.3840934-5-bob.beckett@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220118175036.3840934-5-bob.beckett@collabora.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-01-18 at 17:50:37 +0000, Robert Beckett wrote: > From: Matthew Auld > > On discrete platforms like DG2, we need to support a minimum page size > of 64K when dealing with device local-memory. This is quite tricky for > various reasons, so try to document the new implicit uapi for this. > > v2: Fixed suggestions on formatting [Daniel] > > Signed-off-by: Matthew Auld > Signed-off-by: Ramalingam C > Signed-off-by: Robert Beckett > cc: Simon Ser > cc: Pekka Paalanen > Cc: Jordan Justen > Cc: Kenneth Graunke > Cc: mesa-dev@lists.freedesktop.org > Cc: Tony Ye > Cc: Slawomir Milczarek > --- > include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++----- > 1 file changed, 39 insertions(+), 5 deletions(-) > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index 5e678917da70..486b7b96291e 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 { > /** > * When the EXEC_OBJECT_PINNED flag is specified this is populated by > * the user with the GTT offset at which this object will be pinned. > + * > * When the I915_EXEC_NO_RELOC flag is specified this must contain the > * presumed_offset of the object. > + * > * During execbuffer2 the kernel populates it with the value of the > * current GTT offset of the object, for future presumed_offset writes. > + * > + * See struct drm_i915_gem_create_ext for the rules when dealing with > + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with > + * minimum page sizes, like DG2. > */ > __u64 offset; > > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext { > * > * The (page-aligned) allocated size for the object will be returned. > * > - * Note that for some devices we have might have further minimum > - * page-size restrictions(larger than 4K), like for device local-memory. > - * However in general the final size here should always reflect any > - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS > - * extension to place the object in device local-memory. > + * > + * **DG2 64K min page size implications:** > + * > + * On discrete platforms, starting from DG2, we have to contend with GTT > + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE > + * objects. Specifically the hardware only supports 64K or larger GTT > + * page sizes for such memory. The kernel will already ensure that all > + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page > + * sizes underneath. > + * > + * Note that the returned size here will always reflect any required > + * rounding up done by the kernel, i.e 4K will now become 64K on devices > + * such as DG2. > + * > + * **Special DG2 GTT address alignment requirement:** > + * > + * The GTT alignment will also need be at least 2M for such objects. > + * > + * Note that due to how the hardware implements 64K GTT page support, we > + * have some further complications: > + * > + * 1) The entire PDE(which covers a 2MB virtual address range), must > + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same > + * PDE is forbidden by the hardware. > + * > + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM > + * objects. > + * > + * To keep things simple for userland, we mandate that any GTT mappings > + * must be aligned to and rounded up to 2MB. As this only wastes virtual > + * address space and avoids userland having to copy any needlessly > + * complicated PDE sharing scheme (coloring) and only affects GD2, this > + * id deemed to be a good compromise. "only affects DG2, this is" Except these typos, patch looks good to me Reviewed-by: Ramalingam C > */ > __u64 size; > /** > -- > 2.25.1 >