Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 5/6] drm/xe/xe_migrate.c: Use NULL 1G PTE mapped at 255GiB VA for ccs clear.
Date: Fri, 24 Nov 2023 12:19:09 +0100	[thread overview]
Message-ID: <9ffd93188fb97a3554e56bcee2cefe1ffc4c61a4.camel@linux.intel.com> (raw)
In-Reply-To: <20231121100906.3587649-6-himal.prasad.ghimiray@intel.com>

On Tue, 2023-11-21 at 15:39 +0530, Himal Prasad Ghimiray wrote:
> Get rid of the cleared bo, instead use null 1G PTE mapped at 255GiB
> offset, this can be used for both dgfx and igfx.
> 
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Himal Prasad Ghimiray
> <himal.prasad.ghimiray@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_migrate.c | 56 ++++++-------------------------
> --
>  1 file changed, 10 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_migrate.c
> b/drivers/gpu/drm/xe/xe_migrate.c
> index 06706fad67aa..bdcb20f23531 100644
> --- a/drivers/gpu/drm/xe/xe_migrate.c
> +++ b/drivers/gpu/drm/xe/xe_migrate.c
> @@ -54,8 +54,8 @@ struct xe_migrate {
>         u64 batch_base_ofs;
>         /** @usm_batch_base_ofs: VM offset of the usm batch buffer */
>         u64 usm_batch_base_ofs;
> -       /** @cleared_vram_ofs: VM offset of @cleared_bo. */
> -       u64 cleared_vram_ofs;
> +       /** @cleared_mem_ofs: VM offset of @cleared_bo. */
> +       u64 cleared_mem_ofs;

Can we also remove xe_migrate::cleared_bo?

>         /**
>          * @fence: dma-fence representing the last migration job
> batch.
>          * Protected by @job_mutex.
> @@ -125,41 +125,6 @@ static u64 xe_migrate_vram_ofs(struct xe_device
> *xe, u64 addr)
>         return addr + (256ULL << xe_pt_shift(2));
>  }
>  
> -/*
> - * For flat CCS clearing we need a cleared chunk of memory to copy
> from,
> - * since the CCS clearing mode of XY_FAST_COLOR_BLT appears to be
> buggy
> - * (it clears on only 14 bytes in each chunk of 16).
> - * If clearing the main surface one can use the part of the main
> surface
> - * already cleared, but for clearing as part of copying non-
> compressed
> - * data out of system memory, we don't readily have a cleared part
> of
> - * VRAM to copy from, so create one to use for that case.
> - */
> -static int xe_migrate_create_cleared_bo(struct xe_migrate *m, struct
> xe_vm *vm)
> -{
> -       struct xe_tile *tile = m->tile;
> -       struct xe_device *xe = vm->xe;
> -       size_t cleared_size;
> -       u64 vram_addr;
> -
> -       if (!xe_device_has_flat_ccs(xe))
> -               return 0;
> -
> -       cleared_size = xe_device_ccs_bytes(xe,
> MAX_PREEMPTDISABLE_TRANSFER);
> -       cleared_size = PAGE_ALIGN(cleared_size);
> -       m->cleared_bo = xe_bo_create_pin_map(xe, tile, vm,
> cleared_size,
> -                                            ttm_bo_type_kernel,
> -                                           
> XE_BO_CREATE_VRAM_IF_DGFX(tile) |
> -                                           
> XE_BO_CREATE_PINNED_BIT);
> -       if (IS_ERR(m->cleared_bo))
> -               return PTR_ERR(m->cleared_bo);
> -
> -       xe_map_memset(xe, &m->cleared_bo->vmap, 0, 0x00,
> cleared_size);
> -       vram_addr = xe_bo_addr(m->cleared_bo, 0, XE_PAGE_SIZE);
> -       m->cleared_vram_ofs = xe_migrate_vram_ofs(xe, vram_addr);
> -
> -       return 0;
> -}
> -
>  static int xe_migrate_prepare_vm(struct xe_tile *tile, struct
> xe_migrate *m,
>                                  struct xe_vm *vm)
>  {
> @@ -170,7 +135,6 @@ static int xe_migrate_prepare_vm(struct xe_tile
> *tile, struct xe_migrate *m,
>         u32 map_ofs, level, i;
>         struct xe_bo *bo, *batch = tile->mem.kernel_bb_pool->bo;
>         u64 entry;
> -       int ret;
>  
>         /* Can't bump NUM_PT_SLOTS too high */
>         BUILD_BUG_ON(NUM_PT_SLOTS > SZ_2M/XE_PAGE_SIZE);
> @@ -190,12 +154,6 @@ static int xe_migrate_prepare_vm(struct xe_tile
> *tile, struct xe_migrate *m,
>         if (IS_ERR(bo))
>                 return PTR_ERR(bo);
>  
> -       ret = xe_migrate_create_cleared_bo(m, vm);
> -       if (ret) {
> -               xe_bo_put(bo);
> -               return ret;
> -       }
> -
>         entry = vm->pt_ops->pde_encode_bo(bo, bo->size -
> XE_PAGE_SIZE, pat_index);
>         xe_pt_write(xe, &vm->pt_root[id]->bo->vmap, 0, entry);
>  
> @@ -262,6 +220,12 @@ static int xe_migrate_prepare_vm(struct xe_tile
> *tile, struct xe_migrate *m,
>                           (i + 1) * 8, u64, entry);
>         }

A short comment that we set up a 1GiB NULL mapping at 255GiB offset.

>  
> +       level = 2;
> +       xe_map_wr(xe, &bo->vmap, map_ofs + XE_PAGE_SIZE * level + 255
> * 8, u64,
> +                 vm->pt_ops->pte_encode_addr(xe, 0, pat_index,
> level, IS_DGFX(xe), 0)
> +                 | XE_PTE_NULL);
> +       m->cleared_mem_ofs = (255ULL << xe_pt_shift(level));
> +



>         /* Identity map the entire vram at 256GiB offset */
>         if (IS_DGFX(xe)) {
>                 u64 pos, ofs, flags;
> @@ -616,7 +580,7 @@ static u32 xe_migrate_ccs_copy(struct xe_migrate
> *m,
>                  * Otherwise if the bo doesn't have any CCS metadata
> attached,
>                  * we still need to clear it for security reasons.
>                  */
> -               u64 ccs_src_ofs =  src_is_vram ? src_ofs : m-
> >cleared_vram_ofs;
> +               u64 ccs_src_ofs =  src_is_vram ? src_ofs : m-
> >cleared_mem_ofs;
>  
>                 emit_copy_ccs(gt, bb,
>                               dst_ofs, true,
> @@ -1005,7 +969,7 @@ struct dma_fence *xe_migrate_clear(struct
> xe_migrate *m,
>  
>                 if (xe_device_has_flat_ccs(xe) && clear_vram) {
>                         emit_copy_ccs(gt, bb, clear_L0_ofs, true,
> -                                     m->cleared_vram_ofs, false,
> clear_L0);
> +                                     m->cleared_mem_ofs, false,
> clear_L0);
>                         flush_flags = MI_FLUSH_DW_CCS;
>                 }
>  


  reply	other threads:[~2023-11-24 11:19 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
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 [this message]
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=9ffd93188fb97a3554e56bcee2cefe1ffc4c61a4.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