[enhancement] add a toggle for "unsyncing" on eglswapinterval 0

[kevin gunn]

at the sprint in London, we discussed that the mechanism for the mesa clients is currently to still "sync" on the compositor (even tho its not sync'd on vsync) in order to avoid tearing.
however, its common for clients to accept tearing. Since we do have the ability to keep clients non-tearing with swapinterval 0 we shouldn't throw it out, however we should probably add another toggle in the code to allow for tearing as well with swapinterval 0.

[kevin gunn (kgunn72)]

just for further clarification - i would like this as its useful in performance analysis and inferring load/idle times & debugging vsync issues. I believe another way to look at this is to enable "single buffering" as an option, which means there would need to be an optional config (arch change) to allow for the compositor to read from a buffer that the client is writing into

[Kevin DuBois (kdub)]

"allow for tearing" might not actually have tears on android. Android guarantees 'no tearing' with fences, so the only way to see a tear on the screen is to ignore the fences, and this has a nasty tendency to make internal driver resources grow and make OOM errors happen. (esp on exynos). So while we could enable the buffer queue to do something like this, we shouldn't try to tear out the fences from android.

[kevin gunn (kgunn72)]

could you not tear on the client side ? e.g. allow the client to render as the compositor is reading it for its render ?

[kevin gunn (kgunn72)]

i suppose, that's not a great question, as most benchmarks will be full screen and in bypass mode.

[Daniel van Vugt (vanvugt)]

I think single-buffering (which is presently disabled, but theoretically supportable) is the only real use case for this. And that wouldn't require a toggle "allow tearing" but rather an option in clients for them to request single buffering.

For triple and higher buffering you never need to tear at all. Because a client can render unthrottled to two separate buffers at a very high rate independently of the (slow) screen, without starving the compositor of fresh frames (when it wants them).

So that leaves only double buffering where "enable tearing" would be a usable option. However even then it would only need to tear if you enable framedropping at the same time. Because synchronous double buffering is nice and mutually exclusive; no tearing. That's a very obscure use case and Mir presently doesn't support any double buffering (any more) -- an issue I'm working to resolve.

Given Mir presently maintains the high visual standard of never tearing at all (even for unthrottled clients), I think we need more reminding why this option would ever be desirable. If per comment #1 it's just to support single buffering, then it's a duplicate of bug 1194333.

[kevin gunn (kgunn72)]

this isn't about a normal use case or trying to break "high standards of never tearing". It's about a feature to allow complete saturation of the gpu with no stalling. this is a useful debug tool as well as a mode often used in concert with benchmarking.

[kevin gunn (kgunn72)]

btw, single buffer might be enough, gotta give it a think.

[Daniel van Vugt (vanvugt)]

We can and do already saturate the GPU with no stalling (for benchmarking), if you run:
    mir_demo_client_egltriangle -n

However if you want to saturate the server side, then you can't (yet) and the request makes sense. We already know how to flip non-waiting torn frames; see bug 1274819 :) Although to enable such an option for continuous use would be a significant change to the page flipping logic (separately for each platform).

[kevin gunn (kgunn72)]

right, the idea would be to have an end2end pipeline with no serialized waits, other than gl/gpu calls pending on the gpu load. this way you can see cost of server/compositor, and then (with the already supported client side aspect you mentioned) cost of client side.

[Daniel van Vugt (vanvugt)]

In my experience saturating the GPU makes some platforms unusable. Radeon and nouveau in particular will grind to a halt if you don't throttle your rendering. And an unthrottled client can overwhelm the whole system even while the server is throttled (bug 1211700). But I guess there might be platforms where this kind of stress could be a useful test.

[Launchpad Janitor (janitor)]

[Expired for Mir because there has been no activity for 60 days.]