From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [RFC v2 3/6] drm/xe/xe2: Allocate extra pages for ccs during bo create.
Date: Fri, 24 Nov 2023 12:09:58 +0100 [thread overview]
Message-ID: <797b983ed6313c2866c8b02aa73a5cab1fc4d4a3.camel@linux.intel.com> (raw)
In-Reply-To: <20231121100906.3587649-4-himal.prasad.ghimiray@intel.com>
On Tue, 2023-11-21 at 15:39 +0530, Himal Prasad Ghimiray wrote:
> Each byte of CCS data now represents 512 bytes of main memory data.
> Allocate extra pages to handle ccs region for igfx too.
>
> Bspec:58796
>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Himal Prasad Ghimiray
> <himal.prasad.ghimiray@intel.com>
> ---
> drivers/gpu/drm/xe/regs/xe_gpu_commands.h | 2 +-
> drivers/gpu/drm/xe/xe_bo.c | 15 ++++++---------
> drivers/gpu/drm/xe/xe_device.c | 2 +-
> 3 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/regs/xe_gpu_commands.h
> b/drivers/gpu/drm/xe/regs/xe_gpu_commands.h
> index 4402f72481dc..7f74592f99ce 100644
> --- a/drivers/gpu/drm/xe/regs/xe_gpu_commands.h
> +++ b/drivers/gpu/drm/xe/regs/xe_gpu_commands.h
> @@ -16,7 +16,7 @@
> #define XY_CTRL_SURF_MOCS_MASK GENMASK(31, 26)
> #define XE2_XY_CTRL_SURF_MOCS_INDEX_MASK GENMASK(31, 28)
> #define NUM_CCS_BYTES_PER_BLOCK 256
> -#define NUM_BYTES_PER_CCS_BYTE 256
> +#define NUM_BYTES_PER_CCS_BYTE(_xe) (GRAPHICS_VER(_xe) >= 20 ?
> 512 : 256)
> #define NUM_CCS_BLKS_PER_XFER 1024
>
> #define XY_FAST_COLOR_BLT_CMD (2 << 29 | 0x44 << 22)
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 4305f5cbc2ab..4730ee3c1012 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -2074,19 +2074,16 @@ int xe_bo_evict(struct xe_bo *bo, bool
> force_alloc)
> * placed in system memory.
> * @bo: The xe_bo
> *
> - * If a bo has an allowable placement in XE_PL_TT memory, it can't
> use
> - * flat CCS compression, because the GPU then has no way to access
> the
> - * CCS metadata using relevant commands. For the opposite case, we
> need to
> - * allocate storage for the CCS metadata when the BO is not resident
> in
> - * VRAM memory.
Please extend modify this comment rather than deleting it
> - *
> * Return: true if extra pages need to be allocated, false
> otherwise.
> */
> bool xe_bo_needs_ccs_pages(struct xe_bo *bo)
> {
> - return bo->ttm.type == ttm_bo_type_device &&
> - !(bo->flags & XE_BO_CREATE_SYSTEM_BIT) &&
> - (bo->flags & XE_BO_CREATE_VRAM_MASK);
> + struct xe_device *xe = xe_bo_device(bo);
> +
> + return (xe_device_has_flat_ccs(xe) &&
> + bo->ttm.type == ttm_bo_type_device &&
> + ((IS_DGFX(xe) && (bo->flags &
> XE_BO_CREATE_VRAM_MASK)) ||
It looks like you have removed a restriction for DGFX here: If the BO
has SYSTEM set, then ccs pages are not needed.
> + (!IS_DGFX(xe) && (bo->flags &
> XE_BO_CREATE_SYSTEM_BIT))));
> }
>
> /**
> diff --git a/drivers/gpu/drm/xe/xe_device.c
> b/drivers/gpu/drm/xe/xe_device.c
> index 07a3e4cf48d1..265f9ffc5323 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -551,7 +551,7 @@ void xe_device_wmb(struct xe_device *xe)
> u32 xe_device_ccs_bytes(struct xe_device *xe, u64 size)
> {
> return xe_device_has_flat_ccs(xe) ?
> - DIV_ROUND_UP(size, NUM_BYTES_PER_CCS_BYTE) : 0;
> + DIV_ROUND_UP(size, NUM_BYTES_PER_CCS_BYTE(xe)) : 0;
> }
>
> bool xe_device_mem_access_ongoing(struct xe_device *xe)
next prev parent reply other threads:[~2023-11-24 11:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 10:09 [Intel-xe] [RFC v2 0/6] Enable compression handling on LNL Himal Prasad Ghimiray
2023-11-21 10:09 ` [Intel-xe] [RFC v2 1/6] drm/xe/xe2: Support flat ccs Himal Prasad Ghimiray
2023-11-23 16:28 ` Matthew Auld
2023-11-27 3:04 ` Ghimiray, Himal Prasad
2023-11-24 11:02 ` Thomas Hellström
2023-11-27 3:05 ` Ghimiray, Himal Prasad
2023-11-21 10:09 ` [Intel-xe] [RFC v2 2/6] drm/xe/xe2: Determine bios enablement for flat ccs on igfx Himal Prasad Ghimiray
2023-11-23 16:37 ` Matthew Auld
2023-11-23 17:01 ` Matthew Auld
2023-11-27 3:11 ` Ghimiray, Himal Prasad
2023-11-24 11:05 ` Thomas Hellström
2023-11-27 3:12 ` Ghimiray, Himal Prasad
2023-11-21 10:09 ` [Intel-xe] [RFC v2 3/6] drm/xe/xe2: Allocate extra pages for ccs during bo create Himal Prasad Ghimiray
2023-11-24 11:09 ` Thomas Hellström [this message]
2023-11-27 3:19 ` Ghimiray, Himal Prasad
2023-11-27 9:41 ` Thomas Hellström
2023-11-29 4:53 ` Ghimiray, Himal Prasad
2023-11-21 10:09 ` [Intel-xe] [RFC v2 4/6] drm/xe/xe2: Updates on XY_CTRL_SURF_COPY_BLT Himal Prasad Ghimiray
2023-11-24 11:11 ` Thomas Hellström
2023-11-27 3:21 ` Ghimiray, Himal Prasad
2023-11-21 10:09 ` [Intel-xe] [RFC v2 5/6] drm/xe/xe_migrate.c: Use NULL 1G PTE mapped at 255GiB VA for ccs clear Himal Prasad Ghimiray
2023-11-24 11:19 ` Thomas Hellström
2023-11-27 3:23 ` Ghimiray, Himal Prasad
2023-11-21 10:09 ` [Intel-xe] [RFC v2 6/6] drm/xe/xe2: Handle flat ccs move for igfx Himal Prasad Ghimiray
2023-11-24 15:48 ` Thomas Hellström
2023-11-27 3:25 ` Ghimiray, Himal Prasad
2023-11-28 13:36 ` [Intel-xe] [RFC v2 0/6] Enable compression handling on LNL Thomas Hellström
2023-11-29 4:49 ` Ghimiray, Himal Prasad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=797b983ed6313c2866c8b02aa73a5cab1fc4d4a3.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox