| Message ID | 1424964712-16131-1-git-send-email-deepak.s@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Feb 26, 2015 at 09:01:52PM +0530, deepak.s@linux.intel.com wrote: > From: Deepak S <deepak.s@linux.intel.com> > > The restriction of pinningFramebuffer to first 256MB is removed from gen8+. > Removing the restriction so that FB can be pinned in any space within > GTT/PPGTT. Also, for gen8+ no need to use pin_mappable for Framebuffer & > also we do not take fence as Framebuffer compression is not enabled. Not quite, the reason why we restrict the framebuffer to mappable was that certain display servers depend upon being able to GTT mmap the framebuffer for direct access. Thus they would crash if we found that the framebuffer was already pinned in an unreachable location. That legacy code is currently still able to run on gen8+ and so you need to have userspace request an ABI break... -Chris
On Thu, Feb 26, 2015 at 04:01:32PM +0000, Chris Wilson wrote: > On Thu, Feb 26, 2015 at 09:01:52PM +0530, deepak.s@linux.intel.com wrote: > > From: Deepak S <deepak.s@linux.intel.com> > > > > The restriction of pinningFramebuffer to first 256MB is removed from gen8+. > > Removing the restriction so that FB can be pinned in any space within > > GTT/PPGTT. Also, for gen8+ no need to use pin_mappable for Framebuffer & > > also we do not take fence as Framebuffer compression is not enabled. > > Not quite, the reason why we restrict the framebuffer to mappable was > that certain display servers depend upon being able to GTT mmap the > framebuffer for direct access. Thus they would crash if we found that the > framebuffer was already pinned in an unreachable location. That legacy > code is currently still able to run on gen8+ and so you need to have > userspace request an ABI break... Also, if we do that, we need to make sure we can't bind the buffer at the top of GGTT as we need to be able to prefetch 128 PTEs past the fb? (on SKL 136, "The end of the surface cannot be within 136 PTEs of the end of the graphics memory").
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 77a7315..c9f5b06 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3941,6 +3941,7 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj, struct intel_engine_cs *pipelined) { u32 old_read_domains, old_write_domain; + struct drm_device *dev = obj->base.dev; bool was_pin_display; int ret; @@ -3972,9 +3973,13 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj, /* As the user may map the buffer once pinned in the display plane * (e.g. libkms for the bootup splash), we have to ensure that we - * always use map_and_fenceable for all scanout buffers. + * always use map_and_fenceable for all scanout buffers. No need + * of map_fenceable for >= gen8 */ - ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE); + if ((INTEL_INFO(dev)->gen >= 8)) + ret = i915_gem_obj_ggtt_pin(obj, alignment, 0); + else + ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE); if (ret) goto err_unpin_display; diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index fad5f76..d3067be 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2267,11 +2267,14 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane, /* Install a fence for tiled scan-out. Pre-i965 always needs a * fence, whereas 965+ only requires a fence if using * framebuffer compression. For simplicity, we always install - * a fence as the cost is not that onerous. + * a fence as the cost is not that onerous. Fence is only required + * for gen 7 & below */ - ret = i915_gem_object_get_fence(obj); - if (ret) - goto err_unpin; + if ((INTEL_INFO(dev)->gen <= 7)) { + ret = i915_gem_object_get_fence(obj); + if (ret) + goto err_unpin; + } i915_gem_object_pin_fence(obj);