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.v...@canonical.com <mailto:daniel.van.v...@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.dub...@canonical.com <mailto:kevin.dub...@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@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com> Modify settings or unsubscribe at: https://lists.ubuntu.com/__mailman/listinfo/mir-devel <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
