From: Damien Lespiau <damien.lespiau@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
deepak.s@linux.intel.com, intel-gfx@lists.freedesktop.org,
ville.syrjala@linux.intel.com, "Satyanantha,
Rama Gopal M" <rama.gopal.m.satyanantha@intel.com>
Subject: Re: [RFC] drm/i915: Framebuffers need not be limited to 256MB on gen8+.
Date: Thu, 26 Feb 2015 16:14:50 +0000 [thread overview]
Message-ID: <20150226161450.GA4981@strange.ger.corp.intel.com> (raw)
In-Reply-To: <20150226160132.GC20682@nuc-i3427.alporthouse.com>
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").
--
Damien
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2015-02-26 16:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 15:31 [RFC] drm/i915: Framebuffers need not be limited to 256MB on gen8+ deepak.s
2015-02-26 16:01 ` Chris Wilson
2015-02-26 16:14 ` Damien Lespiau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150226161450.GA4981@strange.ger.corp.intel.com \
--to=damien.lespiau@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=deepak.s@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rama.gopal.m.satyanantha@intel.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox