Commit f28d4266 authored by Chris Wilson's avatar Chris Wilson Committed by Matthew Auld

drm/i915/gt: Move scratch page into system memory on all platforms

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: default avatarChris Wilson <chris.p.wilson@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
Signed-off-by: default avatarMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220926155018.109678-1-matthew.auld@intel.com
parent e5cedf98
...@@ -929,29 +929,30 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt, ...@@ -929,29 +929,30 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
*/ */
ppgtt->vm.has_read_only = !IS_GRAPHICS_VER(gt->i915, 11, 12); 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; ppgtt->vm.alloc_pt_dma = alloc_pt_lmem;
else
/*
* 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 {
ppgtt->vm.alloc_pt_dma = alloc_pt_dma; 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;
ppgtt->vm.pte_encode = gen8_pte_encode; ppgtt->vm.pte_encode = gen8_pte_encode;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment