[PATCH 2/6] compositor-drm: Allow instant start of repaint loop.

[Mario Kleiner]

On 04/13/2015 12:57 PM, Pekka Paalanen wrote:
> On Sun, 12 Apr 2015 23:56:57 +0200
> Mario Kleiner <mario.kleiner.de at gmail.com> wrote:

...

>> Another issue separate from this patch is if/how we could provide some
>> kind of "unredirect fullscreen window" behaviour like on X11 compositors
>> when only 1 client is displaying on an output? That's something i'd
>> really like to have on top of this for timing sensitive / graphics
>> intense clients. If we know there's only one client displaying via zero
>> copy pageflips and no time for composition es needed, maybe we could
>> drive the output repaint directly by that client without the need for a
>> repaint_msec margin? Or reduce that margin to 1 msec? At the moment with
>> a repaint window of 7 msecs, one has to give up almost half a frame
>> duration of rendering time. On a 120 Hz display that would be most of a
>> refresh cycle.
>
> You mean reduce the window automatically to a very small one, which
> mean the compositor would wait almost a full frame period to submit a
> KMS flip just in time?
>

Yes.

> The other option being to submit a KMS flip as soon as a frame comes
> from the client and presume the client manages the timings well.
>
> FWIW, that 7 milliseconds is just something I drew from a hat, and it's
> configurable, but not dynamic. It has been proposed to make it dynamic,
> but we don't yet have all the necessary support in the gfx stack to
> know how long composition actually took and to avoid being delayed by
> client GPU jobs.
>

Yes. One mild usability improvement could be to also allow passing in a 
fractional value, e.g., if repaint-window < 1 then it means a fraction 
of the current video refresh interval, e.g., at 60 Hz 0.5 -> 0.5 * 
16.666 ~ 8 msecs. But really dynamic selection without some 
ability/extension to have something like higer priority for compositor 
vs. clients and some GL_timer_query equivalent in GLES would be difficult.

> Well, composition is not necessary, when all visible surfaces can be put
> into KMS planes. (I think I have a patch somewhere to make Weston avoid
> compositing at all if there is no primary damage this frame.) So, we'd
> need to know when that is possible, and it is probed during
> weston_output_repaint(), in the assign_planes hook.
>
> The problem is that without probing, we don't know if it is possible.
> It's not really enough to check that window geometries and stacking
> etc. doesn't change, a client could submit a buffer that suddenly is
> not scan-out able. Or the KMS could for unrelated reason stop being
> able to scan out from all the surfaces it did before.
>
> We could cache the assign_planes probing results, and if WM state
> doesn't change, re-use it assuming it still works. But what to do when
> it fails and it's too late to composite?
>
> This is a topic for investigation, yes, but it doesn't look easy to me.
> I'd probably suggest to postpone it at least after we have a decent
> atomic KMS support in Weston and can use all hw overlays and cursor
> planes that exist in a unified fashion. I see atomic support as more
> important, and if we had the "unredirect" feature in first, it might
> make implementing atomic harder.
>
> Things to implement would be:
> - detecting when composition is not necessary, carrying it as a hint
> - the assign_planes caching
> - some framework to invalidate the cache
> - attempt to use cached planes info, and fall back to normal repaint if
>    it fails
> - ???
>

I have tried some hackish patches that try stuff like that if you want 
to try:

https://github.com/kleinerm/weston/commits/unredirectexp

It's probably quite a bit brute force and/or hackish, but it seems to 
work ok on a 5 year old Intel HD graphics and didn't seem to crash, hang 
or visually screw up during my testing so far.

It has two deadlines, a early deadline (= your repaint-window) when 
rendering is certainly needed, and a late deadline (= 
late-repaint-window) when rendering can be skipped due to use of direct 
scanout. It assigns planes and calculates damage already in 
weston_output_finish, then decides which deadline to pick, then repeats 
the calculations in the timer callback to see if some new damage etc. 
has invalidated its assumptions. If a fast repaint is no longer possible 
the best it can do is reschedule itself for the next frame. As long as 
the desktops configuration is in some sort of steady state - which it is 
most of the time during normal use - this kind of works. Of course if 
state changes in the wrong moment we'd voluntarily skip a frame, 
although that might not be noticeable, given that those transitions are 
not frequent. Still an imperfect solution arguably, although it seems to 
work fine for fullscreen surfaces. The top-most patch which tries to 
also optimize this way for non-fullscreen hw overlays might be pushing 
this a bit too much, but i just couldn't resist trying :)

-mario

>
>> The most elegant solution would be the presentation_queue extension to
>> simply tell the compositor when one needs stuff onscreen, instead of
>> trying to lock onto the fixed cycle, which may be different for each
>> wayland compositor implementation, and hoping for the best. What are the
>> plans for moving presentation_queue forward?
>
> The queueing work has been stalled for a good while.
> https://bugs.freedesktop.org/show_bug.cgi?id=83092
> It depends on a couple of more fundamental bugs to be fixed first, see
> the blockers. None of this seems to be a priority at the moment.
>
>
> Thanks,
> pq
>