| Message ID | 20220926155018.109678-1-matthew.auld@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915/gt: Move scratch page into system memory on all platforms | expand |
On Mon, 26 Sept 2022 at 16:50, Matthew Auld <matthew.auld@intel.com> wrote: > > From: Chris Wilson <chris.p.wilson@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@intel.com> > Cc: Matthew Auld <matthew.auld@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@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 >
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)