[Intel-gfx] [RFC] drm/i915/skl: Use plane update function from mmio flips

[Tvrtko Ursulin]

On 05/04/2015 02:20 PM, Daniel Vetter wrote:
> On Fri, Apr 24, 2015 at 09:31:56AM +0100, Tvrtko Ursulin wrote:
>>
>> On 04/23/2015 08:15 PM, Daniel Vetter wrote:
>>> On Tue, Apr 21, 2015 at 01:18:57PM +0100, Tvrtko Ursulin wrote:
>>>> On 04/21/2015 11:07 AM, Chris Wilson wrote:
>>>>> On Tue, Apr 21, 2015 at 11:01:03AM +0100, Tvrtko Ursulin wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 04/21/2015 10:51 AM, Chris Wilson wrote:
>>>>>>> On Tue, Apr 21, 2015 at 10:29:52AM +0100, Tvrtko Ursulin wrote:
>>>>>>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>>>>>>
>>>>>>>> Avoids duplicating the code.
>>>>>>>>
>>>>>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>>>>>> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
>>>>>>>> Cc: Sonika Jindal <sonika.jindal at intel.com>
>>>>>>>> Cc: Damien Lespiau <damien.lespiau at intel.com>
>>>>>>>> ---
>>>>>>>> Can we do this?
>>>>>>>
>>>>>>> Sure, but I'd like to see update_primary_plane split into two in that
>>>>>>> case. One to precalcuate the parameters, then the second to apply them
>>>>>>> as we skip the first here (due to doing the setup in process context)
>>>>>>> and want the second to run inside the vblank evasion logic (and the
>>>>>>> unbounded nature of the current update_primary_plane logic scares me).
>>>>>>
>>>>>> What part is unbounded? I don't see anything blocking?
>>>>>
>>>>> The GTT view lookup may have to search through an arbitrary list, it's
>>>>> even controllable by the user. Expect synmark nastiness. This is
>>>>> "trivially" fixable, but this is only the current issue. The bigger issue
>>>>
>>>> That would have to be a framebuffer object operated on from multiple
>>>> contexts so that there are multiple vms? And a lot of them.
>>>>
>>>>> is simply that we have not said that this is a timing critical function
>>>>> and now we are intending to use it from such a context.
>>>>
>>>> It feels like this area is slowly going towards the "too many cooks" state,
>>>> if not already there.
>>>>
>>>>>> As a side note, watermarks seem to be not handled at all in the flip
>>>>>> path as well...
>>>>>
>>>>> The flip path should reject anything that requires a change in line size
>>>>> i.e. a change in WM.
>>>>
>>>> Interesting, well, I had a look around and this means all sorts of "trouble"
>>>> (refactoring) if proper wm param comparison is to be done.
>>>>
>>>> Alternatively, in (more) cheating via embedding knowledge approach, then
>>>> rejecing a change in tiling is simple, but rotation is only known in plane
>>>> state and page flip is not able to compare old vs. new.
>>>>
>>>> In fact, I don't even know if possible since plane properties and page flips
>>>> look disjoint, each living in it's own timeline. If sampled when flip is
>>>> queued it will be bad, if sampled with the flip then it is too late and/or
>>>> properly slow.
>>>
>>> With atomic we can't do such tricks anymore anyway, we always have to
>>> recompute the full state. We'll we could set dirty bits and similar tricks
>>> to avoid recomputing some state and the corresponding setup, but imo that
>>> needs to come with performance data attached. And atm pageflips are
>>> limited to refresh rate.
>>
>> The thing I was raising, and which isn't clear to me, is what ties plane
>> properties with the page flips?
>>
>> Not only what ties them, but what ensures plane properties remain stable
>> between queuing a flip and flipping?
>
> We only allow one in-flight flip atm, and stall before doing any
> synchronous updates. That won't be the case any more once we have a queue,
> but then we should also be converted fully to atomic state objects. And
> with those we can build up a queue of updates. so the flip always knows
> which set of states to pick for a given flip.
>
> Or do I still misunderstand your question?

No idea any longer, I just did not see that flips look (or get) the 
state so was uncertain whether rotation changes from one flip to another 
are possible etc.

Regards,

Tvrtko