Message ID | 1424272568-5920-2-git-send-email-nicholas.hoath@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, Feb 18, 2015 at 03:16:06PM +0000, Nick Hoath wrote:
> Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
That looks reaaaally drastic and without explanations nor W/A
documentation that looks wrong.
Couldn't it be the virtual addresses that need to be on 32 bits? within
a 64bits PPGTT address space? Also this W/A is listed for BDW/CHV. Right
now, we have no way of telling what kind of buffer we're being asked to
relocate into the address space, so there's no way to selectively ensure
some of those buffers end up with a virtual address that remains in the
lower 4GB.
On Wed, Feb 18, 2015 at 06:19:08PM +0000, Damien Lespiau wrote: > On Wed, Feb 18, 2015 at 03:16:06PM +0000, Nick Hoath wrote: > > Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> > > That looks reaaaally drastic and without explanations nor W/A > documentation that looks wrong. > > Couldn't it be the virtual addresses that need to be on 32 bits? within > a 64bits PPGTT address space? Also this W/A is listed for BDW/CHV. Right > now, we have no way of telling what kind of buffer we're being asked to > relocate into the address space, so there's no way to selectively ensure > some of those buffers end up with a virtual address that remains in the > lower 4GB. I915_GEM_DOMAIN_INSTRUCTION is commonly used for all indirect state by mesa, so we could restrict the wa to objects with that reloc. Which means that all the render/texture crap can still be relocated anywhere, which is the majority. Of course that means a full audit of mesa/ddx/libva to make sure we don't break anything. And if there would be breakage we need to make 48bit address spaces opt-in. But yeah restricting all objects and then also applying that restriction to physical objects is _really_ drastic. So please double-check that this is about physical addresses and not virtual addresses. -Daniel
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 5804aa5..df9a3a5 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -748,7 +748,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) * behaviour if any general state is accessed within a page above 4GB, * which also needs to be handled carefully. */ - if (IS_BROADWATER(dev) || IS_CRESTLINE(dev)) + /* Wa32bitGeneralStateOffset:skl */ + if (IS_BROADWATER(dev) || IS_CRESTLINE(dev) || + IS_SKYLAKE(dev)) dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(32)); aperture_size = dev_priv->gtt.mappable_end; diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index dc10d86..00439b5 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4430,7 +4430,9 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev, } mask = GFP_HIGHUSER | __GFP_RECLAIMABLE; - if (IS_CRESTLINE(dev) || IS_BROADWATER(dev)) { + /* Wa32bitInstructionBaseOffset:skl */ + if (IS_CRESTLINE(dev) || IS_BROADWATER(dev) || + IS_SKYLAKE(dev)) { /* 965gm cannot relocate objects above 4GiB. */ mask &= ~__GFP_HIGHMEM; mask |= __GFP_DMA32;
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> --- drivers/gpu/drm/i915/i915_dma.c | 4 +++- drivers/gpu/drm/i915/i915_gem.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-)