HWC Multimonitor work

[Daniel van Vugt]

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
         db->composite()
}

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>
>
>