980321 - make layer updates to the compositor async

Status: RESOLVED INVALID

(Core :: Graphics, defect, P3)

Description

[Ben Kelly [:bkelly, not reviewing]]

In bug 977975 (and others) we saw a couple issues with the way composition work is performed in the gfx IPC message loop:

1) When composition blocks on a video driver lock or fence, synchronous IPC calls from the child process can be blocked for 10+ ms.

2) IPC calls that take a long time, such as allocating and zero'ing a large gralloc buffer, can delay composition and make us miss our frame budget.

If we could find a way to move the CompositeToTarget() work to a separate, non-IPC thread we could potentially avoid these problems.  This would probably cost us some additional data structure locking, but would probably be worth it to avoid stalling the IPC and child processes downstream.

Since I only have a vague notion of the various work done in CompositeToTarget(), though, I'm not sure exactly how hard this is.  My impression is that its harder than it appears.

There is probably also some overlap here with other efforts to move gralloc allocation out of the IPC thread.

Comment 1

[Matt Woodrow (:mattwoodrow)]

The main problem with this is that the majority of the IPC messages coming in are modifying the data structures used within CompositeToTarget.

It seems like we'd be better of moving the gralloc buffer allocation to a separate IPC channel/thread, since that really has no relation to the other messages which all deal with shadowing our Layers objects. I thought this had been done already, but maybe it's still a WIP.

Comment 2

[Andreas Gal :gal]

We discussed this on #gfx and decided that once we have moved gralloc allocation to a separate thread (WIP, pending review), the other fix we want is to have fully async transactions with the compositor. That fixes this problem.

Comment 3

[Matt Woodrow (:mattwoodrow)]

Ok, that sounds good.

We have all the code required for async transactions (and we use them on mac), just our current non-tiled double-buffered textures required a synchronous reply to return the old frontbuffer to content. Tiling won't have this requirement :)

Comment 4

[Sotaro Ikeda [:sotaro]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #3)
> We have all the code required for async transactions (and we use them on
> mac), 

How the client side should wait async replay? Synchronously wait on content side main thread? Or are there other ways to handle it in client side?

Comment 5

[Matt Woodrow (:mattwoodrow)]

(In reply to Sotaro Ikeda [:sotaro] from comment #4)
> (In reply to Matt Woodrow (:mattwoodrow) from comment #3)
> > We have all the code required for async transactions (and we use them on
> > mac), 
> 
> How the client side should wait async replay? Synchronously wait on content
> side main thread? Or are there other ways to handle it in client side?

On OSX, we're not waiting for any reply. The client side allocates a new buffer the size of the invalid region, draws to it and then gives it to the parent. The parent then deallocates the buffer once it's finished uploading it. We could get better performance by asynchronously returning buffers to an allocation pool rather than reallocating all the time.

Tiling basically operates the same way, and already has a pool, so I think we can just work on getting that working everywhere.

Comment 6

[Sotaro Ikeda [:sotaro]]

Thanks, it becomes clear.

Comment 7

[Andreas Gal :gal]

Yeah, lets just do tiling everywhere and then we can kill sync along with buffer rotation. Triple victory.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

Are async transactions doable for 1.4?  It seems like the IPC stalls are probably contributing to checkerboarding by delaying the paints in the child unnecessarily.

Comment 9

[Benoit Girard (:BenWa)]

(In reply to Ben Kelly [:bkelly] from comment #8)
> Are async transactions doable for 1.4?  It seems like the IPC stalls are
> probably contributing to checkerboarding by delaying the paints in the child
> unnecessarily.

We're going to start having more transaction run through the async path in 1.4 since the landing of tiling. We will still see a sync transaction when a thebes layer is updated in that transaction.

Comment 10

[Benoit Girard (:BenWa)]

non tiled (non scrollable) thebes layer.

Comment 11

[Jason Smith [:jsmith]]

Bas - Is this required to implement for 1.4 to hit our APZC targets for 1.4? Trying to figure out if this is required for 1.4 or not.

Comment 12

[Mike Lee [:mlee]]

Per Ben K. this needs to be re-evaluated now that tiling is enabled.

Comment 13

[Benoit Girard (:BenWa)]

(In reply to Jason Smith [:jsmith] from comment #11)
> Bas - Is this required to implement for 1.4 to hit our APZC targets for 1.4?
> Trying to figure out if this is required for 1.4 or not.

No, we're going to start doing more async transaction in 1.4 but we wont have all transaction async for 1.4. It wont gate APZC either.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 15

[Gregory Pappas [:gregp]]

Closing old B2G bugs