[Intel-gfx] [PATCH] drm/i915/gt: Move scratch page into system memory on all platforms

[Matthew Auld]

On Mon, 26 Sept 2022 at 16:50, Matthew Auld <matthew.auld at intel.com> wrote:
>
> From: Chris Wilson <chris.p.wilson at intel.com>
>
> The scratch page should never be accessed, and is only assigned as a
> filler page to redirection invalid userspace access. It is not of a
> performance concern and so we prefer to have a single consistent
> configuration across all platforms, reducing the pressure on device
> memory and avoiding the direct device access that would be required to
> initialise the scratch page.
>
> Signed-off-by: Chris Wilson <chris.p.wilson at intel.com>
> Cc: Matthew Auld <matthew.auld at intel.com>

Makes total sense to me. I was playing around with the ps64 stuff, and
remembered this patch,
Reviewed-by: Matthew Auld <matthew.auld at intel.com>

> ---
>  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 43 ++++++++++++++--------------
>  1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index c7bd5d71b03e..9604edf7d7c2 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -922,29 +922,30 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
>          */
>         ppgtt->vm.has_read_only = !IS_GRAPHICS_VER(gt->i915, 11, 12);
>
> -       if (HAS_LMEM(gt->i915)) {
> +       if (HAS_LMEM(gt->i915))
>                 ppgtt->vm.alloc_pt_dma = alloc_pt_lmem;
> -
> -               /*
> -                * On some platforms the hw has dropped support for 4K GTT pages
> -                * when dealing with LMEM, and due to the design of 64K GTT
> -                * pages in the hw, we can only mark the *entire* page-table as
> -                * operating in 64K GTT mode, since the enable bit is still on
> -                * the pde, and not the pte. And since we still need to allow
> -                * 4K GTT pages for SMEM objects, we can't have a "normal" 4K
> -                * page-table with scratch pointing to LMEM, since that's
> -                * undefined from the hw pov. The simplest solution is to just
> -                * move the 64K scratch page to SMEM on such platforms and call
> -                * it a day, since that should work for all configurations.
> -                */
> -               if (HAS_64K_PAGES(gt->i915))
> -                       ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
> -               else
> -                       ppgtt->vm.alloc_scratch_dma = alloc_pt_lmem;
> -       } else {
> +       else
>                 ppgtt->vm.alloc_pt_dma = alloc_pt_dma;
> -               ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
> -       }
> +
> +       /*
> +        * On some platforms the hw has dropped support for 4K GTT pages
> +        * when dealing with LMEM, and due to the design of 64K GTT
> +        * pages in the hw, we can only mark the *entire* page-table as
> +        * operating in 64K GTT mode, since the enable bit is still on
> +        * the pde, and not the pte. And since we still need to allow
> +        * 4K GTT pages for SMEM objects, we can't have a "normal" 4K
> +        * page-table with scratch pointing to LMEM, since that's
> +        * undefined from the hw pov. The simplest solution is to just
> +        * move the 64K scratch page to SMEM on all platforms and call
> +        * it a day, since that should work for all configurations.
> +        *
> +        * Using SMEM instead of LMEM has the additional advantage of
> +        * not reserving high performance memory for a "never" used
> +        * filler page. It also removes the device access that would
> +        * be required to initialise the scratch page, reducing pressure
> +        * on an even scarcer resource.
> +        */
> +       ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
>
>         err = gen8_init_scratch(&ppgtt->vm);
>         if (err)
> --
> 2.37.3
>