HWC Multimonitor work

[Daniel van Vugt]

Oh, a SingleThreadedCompositor might be infeasible due to:
   https://bugs.launchpad.net/mir/+bug/1395421

And I have a couple of performance fixes that are blocked by that bug 
too. Any takers?


On 12/12/14 09:16, Daniel van Vugt wrote:
> 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>
>>
>>
>