Re: [PATCH 16/18] drm/i915: Overcome display engine stride limits via GTT remapping

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Jul 19, 2018 at 08:01:12PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-07-19 19:22:12)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The display engine stride limits are getting in our way. On SKL+
> > we are limited to 8k pixels, which is easily exceeded with three
> > 4k displays. To overcome this limitation we can remap the pages
> > in the GTT to provide the display engine with a view of memory
> > with a smaller stride.
> > 
> > The code is mostly already there as We already play tricks with
> > the plane surface address and x/y offsets.
> > 
> > A few caveats apply:
> > * linear buffers need the fb stride to be page aligned, as
> >   otherwise the remapped lines wouldn't start at the same
> >   spot
> > * compressed buffers can't be remapped due to the new
> >   ccs hash mode causing the virtual address of the pages
> >   to affect the interpretation of the compressed data. IIRC
> >   the old hash was limited to the low 12 bits so if we were
> >   using that mode we could remap. As it stands we just refuse
> >   to remapp with compressed fbs.
> > * no remapping gen2/3 as we'd need a fence for the remapped
> >   vma, which we currently don't have
> 
> But... you just forbade us getting a fence, there's nothing that
> actually would stop the fence register assignment from working?

Hmm. I thought we still had some kind of fence==object relationship.
Or maybe I'm just thinking about the uapi. I should probably read the
actual code instead of relying on ancient/invalid knowledge :)

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx