[Intel-gfx] [RFC PATCH 00/18] Generic DRRS implementation across the encoders

[Daniel Vetter]

On Tue, Jun 30, 2015 at 11:59:30AM +0530, Ramalingam C wrote:
> 
> On Monday 29 June 2015 09:57 PM, Daniel Vetter wrote:
> >On Mon, Jun 29, 2015 at 04:52:14PM +0530, Ramalingam C wrote:
> >>On Friday 26 June 2015 10:46 PM, Daniel Vetter wrote:
> >>>On Fri, Jun 26, 2015 at 07:21:44PM +0530, Ramalingam C wrote:
> >>>- Static DRRS and generalized seamless DRRS are imo separate features and
> >>>   we should split the patch series. seamless DRRS is already implemented
> >>>   using the fb tracking, maybe extended with some hints to userspace.
> >>>
> >>>   Static DRRS otoh is just a modeset with a different clock (plus a better
> >>>   internal implementation to avoid flicker). So from that pov two
> >>>   completely different features, both in the implementation and the
> >>>   userspace ABI.
> >>Yup. Static is not even in our development radar :). All the code that I
> >>have shared is
> >>concerned only with seamless DRRS and it's two usecase scenarios( Idleness
> >>and Content based).
> >>Mentioned the Static DRRS in cover letter, just to give the two different
> >>DRRS supports available in general.
> >Hm then I'm confused how the content based DRRS is supposed to work. I
> >thought userspace requires a precise vrefresh rate (adjusted to content,
> >within the limits of what the panel can do ofc) and the kernel tries to
> >obey. That's what I consider static DRRS, i.e. userspace makes a fixed
> >request, kernel executes it exactly.
> If panel does support the static DRRS only and you are ok to do a complete
> modeset on a usecase then
> Whatever you have explained stands true for content based DRRS. I believe
> its another complete modeset w.r.t kernel.
> Which I am not addressing in this RFC.
> 
> But If the panel supports seamless DRRS and userspace want a precise
> vrefresh rate (adjusted to the
> content, within the limits of what panel can do) then kernel can achieve the
> vrefresh change seamlessly
> (the way its done with Idleness scenario). This is the second usecase of
> seamless DRRS support of the panel.
> Infact We have implemented this and verified on android already for video
> playback.
> >
> >Seamless DRRS for me is when the kernel tries to change vrefresh when
> >everything is idle behind everyone's back.
> Seamless DRRS is a capability of the host and the panel. Usercase definition
> is upto us to do.
> >
> >I'm doing this split since seamless doesn't require new userspace
> >interfaces (we just use the frontbuffer tracking system), whereas static
> >needs explicit action from userspace and hence the dreaded userspace ABI
> >problem starts to kick in.
> Based on above usecase of the seamless drrs we need a fast modeset path
> which I have addressed at the RFC PATCH 16/18.
> And drm connector property to expose the SEAMLESS DRRS capability to the
> userspace. implemented at RFC PATCH 18/18

Summarizing our discussion from the mtg, there's 3 different cases here:
- transparent seamless DRRS where the kernel lowers vrefresh on idle
  behind userspace's back. This is what we currently have integrated. No
  new ABI required.
- seamless DRRS but upon explicit request from userspace. This is
  essentially just a mode change, but excuted by the kernel without any
  blanking or otherwise stalling. We can reuse the modeset ioctls for
  this, just need a fast path (similar to the fast pfit update Maarten
  already has in his atomic branches). For figuring out whether seamless
  is possible we could reuse the atomic TEST_ONLY and ALLOW_MODESET flags.
  Good chances that we don't need a new ABI.
- just changing the vrefresh of the panel, with full modeset/blanking. We
  have the interface for that (we can do modesets), but currently our
  panel compute_config code hardcodes the vrefresh to the preferred mode
  of the panel. We need to change that and pick the vrefresh userspace
  asked for. I think from an implementation pov it makes sense to first
  fix up this case, and then in a 2nd step implement the seamless DRRS for
  explicit mode changes.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch