Re: [RFC PATCH 00/18] Generic DRRS implementation across the encoders

From: Ramalingam C <ramalingam.c@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: paulo.r.zanoni@intel.com, daniel.vetter@ffwll.ch,
	intel-gfx@lists.freedesktop.org, rodrigo.vivi@intel.com
Subject: Re: [RFC PATCH 00/18] Generic DRRS implementation across the encoders
Date: Tue, 30 Jun 2015 11:59:30 +0530	[thread overview]
Message-ID: <5592374A.9080601@intel.com> (raw)
In-Reply-To: <20150629162710.GC30960@phenom.ffwll.local>


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
>
> Do you have different definitions? What exactly are those?
-Daniel

-- 
Thanks,
--Ram

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx