HWC Multimonitor work

Daniel van Vugt daniel.van.vugt at canonical.com
Fri Dec 12 01:16:23 UTC 2014

So if you need separate display buffers but a single thread then what if 
you just replaced MultiThreadedCompositor with a 
SingleThreadedCompositor which does:

while (running)
     wait for frame(s)
     for each display buffer db

That will work providing you employ parallelism like in Mesa such that 
you're never waiting on the next page flip inside composite(); only 
waiting on the page flip of the previous frame. Although I think you're 
pointing out already that Android isn't that flexible?...

Yet another option would be the compromise we have in X/Compiz right 
now. Just sync to vblank on one output only (and accept tearing on all 
the others).

On 12/12/14 03:03, Kevin DuBois wrote:
> @OverlappingOutputGroup
> The first goal is to have a clone mode, so the OverlappingOutputGroup
> could be a good trick. (We can't designate scanout of a sub-rectangle of
> a larger framebuffer surface in HWC though, so might be difficult)
> If we try to have different-content monitors that really don't overlap
> though, I'd want to present the DisplayBuffers as separate, so at some
> point in the future we'd have to give some hint or requirement from the
> platform to the server about what's the best way to drive the
> composition loop.
> Expounding on point 3) a bit more, a bit more input from the platform
> about how to run the loop would help robustify against drivers with
> weird fencing problems (which we've hit in bringup), as it aligns the
> compositor-drive-model that the drivers are best-tested with. We can
> also properly implement the HWC invalidate() callback (which, isnt used
> very often, but we currently just drop the request)
> @different refresh rate,
> If there are 2 sets inbetween the pageflips, the last one sticks for
> that display. IMO Mesa has thought about multimonitor better in its api,
> and 'don't break mesa's goodness" is a goal in accommodating HWC.
> On Wed, Dec 10, 2014 at 9:50 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> wrote:
>     Even displays of the same refresh rate are a problem (see in
>     X/Compiz where all but one of your displays will tear).
>     In Mir (the DRM platform) we've solved this with parallel rendering
>     while waiting for the previous page flips. Because if you have
>     multiple monitors at the same refresh rate, the upper limit on time
>     to wait for vsync on all of them is (asymptotically) double that of
>     a single monitor.
>     It's possible HWC could support such an approach, so long as we have
>     the required triple-buffering in the compositor.
>     On 11/12/14 10:31, Christopher James Halse Rogers wrote:
>         On Thu, Dec 11, 2014 at 7:59 AM, Kevin DuBois
>         <kevin.dubois at canonical.com <mailto:kevin.dubois at canonical.com>>
>         wrote:
>             Details of why:
>             HWC's prepare() and set() functions post to all the displays
>             in one call.
>         Incidentally, how does this work with displays of different refresh
>         rate? Does HWC drop pending flips when a new flip is scheduled?
>     --
>     Mir-devel mailing list
>     Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>

More information about the Mir-devel mailing list