Artificial performance limitation

[Daniel van Vugt]

Detailed profile graph (.SVG) attached, thanks to Google's profiler.

Notice the CompositingFunctor where ~vector is consuming 30% of the 
time, due to ~TemporaryCompositorBuffer taking 27% of the time.

I think we need to move the final buffer release/response logic out of 
the compositor thread (even not using callbacks?). And occluded ones 
too, need to be released in a more controlled environment (not in an 
alarm's mainloop thread where they will all queue up and contend).

With some luck, someone might have done so before I wake up...


On 03/11/14 08:36, Daniel van Vugt wrote:
> This bug and its sister bug are driving me crazy:
> https://bugs.launchpad.net/mir/+bug/1388490
> https://bugs.launchpad.net/mir/+bug/1377872
>
> I can see in both cases that the frame rate ceiling is arbitrary and
> temporary. It has nothing at all to do with the power of the host. And
> the workaround that fixes the problem in both cases is a bit crazy.
>
> I've so far investigated theories around:
>    * buffer lifetimes
>    * Mesa/intel GL batching bugs
>    * lock contention (locks held too long)
>    * power management modes
>    * Mir socket/protocol bottlenecks
>
> All the theories have some merit but I am not making progress. If you
> are (un)lucky enough to be able to reproduce either bug then please join
> in. More data points are required.
>
> - Daniel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mir-demo-shell-google-profile.svg
Type: image/svg+xml
Size: 116139 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20141112/ee812fba/attachment-0001.svg>