On 04/13/2015 12:57 PM, Pekka Paalanen wrote:
On Sun, 12 Apr 2015 23:56:57 +0200
Mario Kleiner <[email protected]> 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
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
