972619 - Perf regressions with tiling on b2g

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Benoit Girard (:BenWa)]

Let's start looking into the performance regressions now:

http://people.mozilla.org/~bgirard/cleopatra/#report=4091a804495fce616cb1161bd36e810e8c2c33ae&select=7783,9443

Quickly two things stand out:
1) We're using shmem instead of gralloc
2) Spending a lot more time issuing draw calls

Comment 1

[Chris Lord [:cwiiis]]

To be clear, I meant it was a regression vs tiling without the patch.

Comment 2

[Benoit Girard (:BenWa)]

Alright please ignore the profile in the description. It was gathered on the Nexus 7 and it doesn't seem to really match performance of what we are shipping.

Here's a profile of the tiling worse case compared to buffer rotation:
http://people.mozilla.org/~bgirard/Invalidation/tiling/2by2.html

http://people.mozilla.org/~bgirard/cleopatra/#report=5b3cfc6300cff0c9d6dfe3f5a9b847dec85be652

Bottleneck is on IPDL::PTexture::SendRemoveTextureSync

Comment 3

[Benoit Girard (:BenWa)]

Here's a better profile with stackwalking:
http://people.mozilla.org/~bgirard/cleopatra/#report=b9e1208d05c595591a8a06734432ccbfeb4a329d

This profile is very flat :(

Comment 4

[Benoit Girard (:BenWa)]

Here's what sticks out the most:

15% de-allocating texture client - We should consider either tripple buffering explicitly or blocking on the swap when paint the second time and not when we send the transaction.
2.5% allocating texture client
15% filling 16 pixels - This needs to be checked
10% clearing a surface? - Need to find what this clear here, unwind is failling
10% sending an async transaction - Why did this get so expensive?

Comment 5

[Benoit Girard (:BenWa)]

(In reply to Benoit Girard (:BenWa) from comment #4)
> 10% clearing a surface? - Need to find what this clear here, unwind is
> failling

Alright I added more probes. I'm seeing 15% in this profile due to CopySurface and 5% for the allocation.

Looks like we really need to deal with the tiles contention case.

Comment 6

[Andreas Gal :gal]

What is the tiles contention case?

Comment 7

[Benoit Girard (:BenWa)]

Right now on Fennec we have a texture as a front buffer which we can't swap (no gralloc). So we use a single back buffer for the tile. On subsequent paints if the back buffer still hasn't been copied to the front buffer yet by the compositor  (contention for the back buffer), then the main thread will allocate a new back buffer, copy from the locked backbuffer and draw new content in it. When the compositor catches up it will discard the extra buffer allocated.

For Fennec this worked well when we had backbuffer contention but we used main memory (not shmem) so there was a lot less overhead to allocate a back buffer. Looks like this isn't working well in the multi-process case.

Comment 8

[Benoit Girard (:BenWa)]

This bug was meant to deal with the perf regression of a direct port of tiling between fennec and b2g. This is no longer valid as we port tiling to the new layers code.