[Flame] Unable to use full HW composition in most of use case

RESOLVED INACTIVE

Status

()

Core
Graphics: Layers
RESOLVED INACTIVE
4 years ago
16 minutes ago

People

(Reporter: schiu, Assigned: schiu)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
I am current checking the HWC function on Flame, and it seems really difficult to perform full HW composition for many use case. Compare to below use cases in Leo, full HW composition cannot be performed in Flame, 

1. home screen scrolling, 
2. scrolling in Setting, 
3. camera previewing, 
4. video playback

Its seems all of mList->hwLayers[j].compositionType still stay in HWC_FRAMEBUFFER after Prepare() being called. 

One thing I noticed is, when I turn on the debugging log in libhwcomposer(by using "adb shell setprop debug.mdpcomp.logs", and then restart b2g),
I found libhwcomposer complained about insufficient pipe:

I/Gecko   (  304): solomon: hwLayer[0]: gLayer=ColorLayerComposite, compositionType=0
I/Gecko   (  304): solomon: hwLayer[1]: gLayer=ThebesLayerComposite, compositionType=0
I/Gecko   (  304): solomon: hwLayer[2]: gLayer=ThebesLayerComposite, compositionType=0

D/qdhwcomposer(  304): arePipesAvailable: Insufficient pipes, dpy 0 needed 4, avail 1
D/qdhwcomposer(  304): loadBasedCompPreferGPU: Not attempting
D/qdhwcomposer(  304): updateLayerCache: MDP count: 0 FB count 4 drop count: 0
D/qdhwcomposer(  304): updateYUV: fb count: 4
D/qdhwcomposer(  304): GEOMETRY change: 1
E/qdhwcomposer(  304): HWC Map for Dpy: "PRIMARY"
E/qdhwcomposer(  304): CURR_FRAME: layerCount: 4 mdpCount: 0 fbCount: 4
E/qdhwcomposer(  304): needsFBRedraw:YES  pipesUsed: 0  MaxPipesPerMixer: 4
E/qdhwcomposer(  304):  ---------------------------------------------
E/qdhwcomposer(  304):  listIdx | cached? | mdpIndex | comptype  |  Z
E/qdhwcomposer(  304):  ---------------------------------------------
E/qdhwcomposer(  304):        0 |     YES |       -1 |      GLES |  0
E/qdhwcomposer(  304):        1 |     YES |       -1 |      GLES |  0
E/qdhwcomposer(  304):        2 |     YES |       -1 |      GLES |  0
E/qdhwcomposer(  304):        3 |     YES |       -1 |      GLES |  0
E/qdhwcomposer(  304):

I also check the pipe config at boot time, and got:

E/qdutils (  304): mRGBPipes=0, mVGPipes=0, mDMAPipes=1
E/qdoverlay(  304): NUM_PIPES=1

Comment 1

4 years ago
Solomon,

The pipe configuration is correct for Flame device. Are you testing on v1.4 build? Because I do not see these error logs on v1.4 build with same reference device. Ideally, when we enable "debug.mdpcomp.logs" on this device, we should see the log since it is not H/W Overlay device:

draw: MDP Comp not configured

Can you please pull and share the system prop settings related to display from the device (from /system/build.prop file)?
Flags: needinfo?(schiu)
(Assignee)

Comment 2

4 years ago
Created attachment 8431695 [details]
build.prop of Flame
Flags: needinfo?(schiu)
(Assignee)

Comment 3

4 years ago
(In reply to Sushil from comment #1)
> Solomon,
> 
> The pipe configuration is correct for Flame device. Are you testing on v1.4
> build? Because I do not see these error logs on v1.4 build with same
> reference device. Ideally, when we enable "debug.mdpcomp.logs" on this
> device, we should see the log since it is not H/W Overlay device:
> 
> draw: MDP Comp not configured
> 
> Can you please pull and share the system prop settings related to display
> from the device (from /system/build.prop file)?

Hi Sushil,

I am testing in 2.0. An use case that I used to test full HWC is: launch 3 or more applications, and then enter Card-view by long pressing the home key. Then there will 3 gecko layers for composition. 

Please let me know if you need more information for debugging.

Thanks.
Flags: needinfo?(sushilchauhan)

Comment 4

4 years ago
Hi Solomon,

The build.prop file looks fine. If you are not able to use HWC entirely like not even in Video playback, Camera preview, etc. then it is a concern. Please sync-up with Sotaro, as he is able to use HWC on v1.4 Flame. On the other hand, if you are reporting that HWC is not being used in some specific use case, then please enable LOGE in HwcComposer2D::PrepareLayerList() to check at which point we are returning false in that use case. I suspect null gralloc buffer check due to presence of tiled layers in frame.
Flags: needinfo?(sushilchauhan)
I seems to understand the cause of the problem. Comment 0's regression seems to be caused by the following reasons.
- [1] For scrolling layer, tiled layer is used since b2g-v1.4.
        Current b2d does not support hw composer composition of tiled layer.
- [2] Flame(msm8610) has Copybit MDP HwComposer
        old b2g hardwares(like hamachi) has overly MDP
- [3] msm8610's Copybit MDP HwComposer does not do composition if total rendering size exceeds "framebuffer size * 1.5".


[3] is implemented in CopyBit::canUseCopybitForRGB().
https://www.codeaurora.org/cgit/quic/qrd-android/platform/hardware/qcom/display/tree/libhwcomposer/hwc_copybit.cpp#n80
1.5 is defined by debug.hwc.dynThreshold. It's value seems still 1.4 in KK.
https://www.codeaurora.org/cgit/quic/la/platform/vendor/qcom/msm8610/tree/system.prop?h=b2g_kk_3.5#n30
One more.
- [4] will-change CSS property add more layers.

[4] is implemented by Bug 940842.
From my analysis, it is not a gonk integration problem but graphics problem. Change the component to Graphics.
Component: GonkIntegration → Graphics: Layers
Product: Firefox OS → Core
(In reply to Sotaro Ikeda [:sotaro] from comment #5)
> - [2] Flame(msm8610) has Copybit MDP HwComposer
>         old b2g hardwares(like hamachi) has overly MDP
> - [3] msm8610's Copybit MDP HwComposer does not do composition if total
> rendering size exceeds "framebuffer size * 1.5".

[2] and [3] is very important point for flame device. msm8610's HwComposer has a capability to compose layers up to 32 layers. But it does not do composition if total
> rendering size exceeds "framebuffer size * 1.5". On b2g, this threshold is exceeded only when status bar is shown on the display.
On flame, when status bar is shown on the display, it never uses hw composer. For example, even crystalskull app does not use HwComposer. The crystalskull occupies whole display except the statusbar with WebGL canvas. But even that configuration does not use HwComposer.

When the crystalskull is running, "total render area" and "frame buffer area" is the following. It is on master flame. It render 2.9 times more than actual frame buffer area size :-(

> total render area= 1199232, frame buffer area= 409920

HwComposer usage limit is 1.5. 2.9 is much bigger than 1.5.
Comment about the STR in Comment 0.

> 1. home screen scrolling, 

In the past homescreen sometimes uses hw composer's composition on hamachi. But on recent b2g, hw composer is not used at all. It seems to be caused by [4]. To speed up the UP response, homescreen app is layered more than before.

As in Commment 9, frame device does not use HwCompser when status bar is shown.

> 2. scrolling in Setting, 

For scrolling layer, b2g uses tiled layer since b2g-v1.4. B2g does not support tiled layer for the time being. Even when tiled layer is supported, flame does not use HwComposer because of total rendering size problem.

> 3. camera previewing, 

On flame, camera preview UI used tiled layer for UI. Tiled layer is not supported on current b2g.

> 4. video playback

When status bar is shown, HwComposer is not used because of total rendering size problem. In fullscreen case, tiled layer is used on the background. Therefore, hw composer is not used.

Fullscreen video playback uses HwComposer on latest master flame. It is fixed by Bug 988511.



Bug 988511
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> Comment about the STR in Comment 0.
> 
> > 1. home screen scrolling, 
> 
> In the past homescreen sometimes uses hw composer's composition on hamachi.
> But on recent b2g, hw composer is not used at all. It seems to be caused by
> [4]. To speed up the UP response, homescreen app is layered more than before.
> 
> As in Commment 9, frame device does not use HwCompser when status bar is
> shown.
> 
> > 2. scrolling in Setting, 
> 
> For scrolling layer, b2g uses tiled layer since b2g-v1.4. B2g does not
> support tiled layer for the time being. Even when tiled layer is supported,
> flame does not use HwComposer because of total rendering size problem.
> 
> > 3. camera previewing, 
> 
> On flame, camera preview UI used tiled layer for UI. Tiled layer is not
> supported on current b2g.
> 
> > 4. video playback
> 
> When status bar is shown, HwComposer is not used because of total rendering
> size problem. In fullscreen case, tiled layer is used on the background.
> Therefore, hw composer is not used.
> 
> Fullscreen video playback uses HwComposer on latest master flame. It is
> fixed by Bug 988511.

Sorry, Correction:

Local video playback by using video app uses HwComposer. It does not show status bar and does not have scrollable layer. Bug 988511 fixes Youtube video playback case.
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> 
> > 3. camera previewing, 
> 
> On flame, camera preview UI used tiled layer for UI. Tiled layer is not
> supported on current b2g.

I confirmed that by disabling tiling, camera preview uses HwComposer.
Bug 1022158 is created for camera preview problem.
(In reply to Sotaro Ikeda [:sotaro] from comment #9)
> On flame, when status bar is shown on the display, it never uses hw
> composer. For example, even crystalskull app does not use HwComposer. The
> crystalskull occupies whole display except the statusbar with WebGL canvas.
> But even that configuration does not use HwComposer.
> 
> When the crystalskull is running, "total render area" and "frame buffer
> area" is the following. It is on master flame. It render 2.9 times more than
> actual frame buffer area size :-(
> 
> > total render area= 1199232, frame buffer area= 409920
> 
> HwComposer usage limit is 1.5. 2.9 is much bigger than 1.5.


Bug 1022164 is created for crystalskull's problem.

Comment 15

16 minutes ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 16 minutes ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.