Closed
Bug 1015332
Opened 10 years ago
Closed 10 years ago
Youtube video playback in Browser is not using H/W composition.
Categories
(Core :: Graphics: Layers, defect, P2)
Tracking
()
RESOLVED
DUPLICATE
of bug 988511
mozilla32
People
(Reporter: sushilchauhan, Assigned: sushilchauhan)
References
Details
(Keywords: perf, power, Whiteboard: [c=power p= s=2014.06.06.t u=] [caf priority: p1][CR 669803])
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
sushilchauhan
:
review+
|
Details | Diff | Splinter Review |
Youtube video playback in Browser is not using H/W Composition. It is falling back to GPU Composition due to NULL gralloc buffer for Thebes layer. Here is log: HWC layer[0]::ColorLayerComposite: dst=[0 0 1080 1920] src=[0 0 1920 1080] E/HWComposer( 217): ThebesLayer Layer doesn't have a gralloc buffer GPU Composition impacts power numbers in this use case. Can you please check why the gralloc buffer is NULL in this use case ? Video playback in Video app is fine and using H/W Composition.
Comment 2•10 years ago
|
||
Is the layer scrollable? If so we are using tiling, and H/W composition is not possible. YT video playback in the browser has traditionally not been a test case we have used for CS. Does Chrome use H/W composition in this case?
How to disable tiled rendering, just to verify if it uses H/W Composition ? It seems Bug 988851 has been re-opened (from dup). BTW, it is also happening on full screen landscape 720p Video in Youtube on Browser, which should not be scrollable since it is full screen and should be the only layer in frame.
Comment 4•10 years ago
|
||
Sotaro, Is this a regression? Power impact here?
Flags: needinfo?(sotaro.ikeda.g)
Updated•10 years ago
|
Comment 6•10 years ago
|
||
(In reply to Sushil from comment #3) > How to disable tiled rendering, just to verify if it uses H/W Composition ? The option is a true/false, layers.enable-tiles, true by default. You should also see it in the developer menu if you can run the phone first, then change the value.
Comment 8•10 years ago
|
||
(In reply to Preeti Raghunath(:Preeti) from comment #4) > Sotaro, > > Is this a regression? Power impact here? It could make some regression to the power consumption. But I am not sure the regression could have a value to be "b2g v1.4+". There was a similar bug about camera. It is Bug 995680.
Flags: needinfo?(sotaro.ikeda.g)
Comment 9•10 years ago
|
||
(In reply to Preeti Raghunath(:Preeti) from comment #4) > Sotaro, > > Is this a regression? As in bug 988511, on b2g v1.3, on youtube video fullscreen playback, hw composer was used.
Comment 10•10 years ago
|
||
Mike Please weigh in on regression on power consumption
Flags: needinfo?(mlee)
Updated•10 years ago
|
Priority: -- → P2
Whiteboard: [CR 669803] → [CR 669803][c=power p= s= u=]
Updated•10 years ago
|
blocking-b2g: 1.4? → -
Flags: needinfo?(mlee)
Comment 11•10 years ago
|
||
From Triage: Dependent bug 988511, comment #7 - https://bugzilla.mozilla.org/show_bug.cgi?id=988511#c7 - This is not a blocker because the power usage from the network should use more than the GPU.
Comment 12•10 years ago
|
||
The logic that network probably uses more power so it's okay to use GPU instead of using HWC doesn't make sense. It's based on assumption and also this is such a common use case so we should try to optimize on power consumption in all aspects. We should definitely try to fix it at least for 2.0 and if possible in v1.4 as well.
Updated•10 years ago
|
blocking-b2g: - → 2.0?
Comment 14•10 years ago
|
||
I'm assuming bug 988511 is the first priority - YouTube videos in full screen.
Flags: needinfo?(milan)
Assignee | ||
Comment 15•10 years ago
|
||
In HwcComposer2D, if we mark the layer having NULL gralloc buffer as HWC_SKIP_LAYER instead of forcing the entire frame to use GPU Composition, we can still use HWC for other layers in the frame. We just checked & verified that full screen and non-full screen Youtube video playback is using HWC by doing this. This will save power during Youtube video playback. I will upload the patch. Meanwhile, please debug why HwcComposer2D is getting NULL gralloc buffer when tiling is enabled (Bug 988511).
Assignee | ||
Comment 16•10 years ago
|
||
On platforms with partial HWC Composition support, mark the layers with NULL gralloc buffer, as HWC_SKIP_LAYER, to have them composed by GPU, so remaining layers get composed by HWC. It gives an opportunity to save power, by avoiding fallback to GPU Composition entirely.
Assignee: nobody → sushilchauhan
Status: NEW → ASSIGNED
Attachment #8432053 -
Flags: review?(dwilson)
Assignee | ||
Comment 17•10 years ago
|
||
Comment on attachment 8432053 [details] [diff] [review] Optimize frame having layers with NULL gralloc buffer. Adding Sotaro to review the patch.
Attachment #8432053 -
Flags: review?(dwilson) → review?(sotaro.ikeda.g)
Comment 18•10 years ago
|
||
Will it fall back to full GPU if it doesn't support partial HWC composition?
Flags: needinfo?(sushilchauhan)
Assignee | ||
Comment 19•10 years ago
|
||
Yes, HAL will take the decision whether the frame can take partial HWC Composition path or full GPU Composition. By marking as HWC_SKIP_LAYER, we are telling HWC that do not compose this layer, it will be composed by GPU. And ANDROID_VERSION check is needed since ICS based HALs do not support partial HWC Composition.
Flags: needinfo?(sushilchauhan)
Comment 20•10 years ago
|
||
Comment on attachment 8432053 [details] [diff] [review] Optimize frame having layers with NULL gralloc buffer. Review of attachment 8432053 [details] [diff] [review]: ----------------------------------------------------------------- Hijacking r? from Sotaro. LGTM
Attachment #8432053 -
Flags: review?(sotaro.ikeda.g) → review+
Comment 21•10 years ago
|
||
(In reply to Sushil from comment #17) > Comment on attachment 8432053 [details] [diff] [review] > Optimize frame having layers with NULL gralloc buffer. > > Adding Sotaro to review the patch. The patch looks just skip tiled layer. How tiled layer is drawn?
Updated•10 years ago
|
Flags: needinfo?(sushilchauhan)
Assignee | ||
Comment 22•10 years ago
|
||
> > The patch looks just skip tiled layer. How tiled layer is drawn? Tiled layer is drawn by GPU. We are just asking HWC hal not to compose this layer by marking it as HWC_SKIP_LAYER. Meanwhile, you will still need to debug (in Bug 988511) why the gralloc buffer handle is NULL when tiling is enabled. And fortunately, in YouTube use case, all layers other than Video layer do not change most of the times, so we land-up in using cache-based partial HWC Composition which saves lot of power. And in full screen landscape YouTube, the tiled layer is actually behind the full screen opaque Video layer, so only Video layer gets composed by HWC, which again saves power by avoiding GPU entirely.
Flags: needinfo?(sushilchauhan)
Comment 23•10 years ago
|
||
Sushi, can you explain more concretely about by which code the tiled layer is rendered by gpu?
Flags: needinfo?(sushilchauhan)
Assignee | ||
Comment 24•10 years ago
|
||
Sotaro, Let's say YouTube frame has 2 layers: Layer[0]: Tiled layer, with null gralloc buffer. We mark it HWC_SKIP_LAYER, comp type = HWC_FRAMEBUFFER Layer[1]: Video layer, comp type = HWC_FRAMEBUFFER In mHwc->prepare(), HAL does not touch Layer[0] but change composition type of Layer[1] to HWC_OVERLAY since it can compose the Video layer. After mHwc->prepare(), [1] and [2] takes care of letting GPU render the Layer[0] on FB layer, then we get the Render() call at [3] which includes eglSwapBuffers() call via [4] followed by Commit() call at [5], hence both FB layer (which has the content composed by GPU) and Layer[1] are now drawn by HWC in mHwc->set(). This is called partial HWC Composition path. [1]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#557 [2]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#582 [3]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#606 [4]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#613 [5]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#639
Flags: needinfo?(sushilchauhan)
Assignee | ||
Comment 26•10 years ago
|
||
Uploading HG friendly version of the reviewed patch.
Attachment #8432053 -
Attachment is obsolete: true
Attachment #8433632 -
Flags: review+
Assignee | ||
Comment 27•10 years ago
|
||
Sotaro, can you please run the patch: attachment 8433632 [details] [diff] [review] on Try server and share the link ?
Flags: needinfo?(sotaro.ikeda.g)
Comment 28•10 years ago
|
||
(In reply to Sushil from comment #27) > Sotaro, can you please run the patch: attachment 8433632 [details] [diff] [review] > [review] on Try server and share the link ? Ok. I am going push to tryserver.
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 30•10 years ago
|
||
Try server link: https://tbpl.mozilla.org/?tree=Try&rev=45aafb02841e
blocking-b2g: 2.0? → 1.4?
Keywords: checkin-needed
Comment 31•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/2a4cde9c1130
Keywords: checkin-needed
Comment 32•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/2a4cde9c1130
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Comment 34•10 years ago
|
||
(In reply to Preeti Raghunath(:Preeti) from comment #33) > Already in 2.0. Not taking it in 1.4 Any reason not to take for 1.4, this gives power savings which would help in battery life
Updated•10 years ago
|
Whiteboard: [CR 669803][c=power p= s= u=] → [caf priority: p2][CR 669803][c=power p= s= u=]
Assignee | ||
Comment 35•10 years ago
|
||
Power savings in YouTube on Browser, which is a popular use-case.
Updated•10 years ago
|
Whiteboard: [caf priority: p2][CR 669803][c=power p= s= u=] → [c=power p= s=2014.06.06.t u=] [caf priority: p2][CR 669803]
Comment 37•10 years ago
|
||
(In reply to bhargavg1 from comment #36) > ni Preeti as to consider for 1.4 Please provide risk analysis here as I am concerned with taking too many blockers in 1.4
Flags: needinfo?(praghunath) → needinfo?(sushilchauhan)
Comment 39•10 years ago
|
||
(In reply to Preeti Raghunath(:Preeti) from comment #37) > (In reply to bhargavg1 from comment #36) > > ni Preeti as to consider for 1.4 > > Please provide risk analysis here as I am concerned with taking too many > blockers in 1.4 I think bug 1020527 already answers this question. Way too risky for 1.4 at this point.
Flags: needinfo?(sushilchauhan)
Comment 40•10 years ago
|
||
Sorry, I had to back this out because of bug 1020527. https://hg.mozilla.org/mozilla-central/rev/951e3a671279
Updated•10 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 41•10 years ago
|
||
Sotaro, since you reproduced the issue on your device, I have couple of questions: 1. How to reproduce that sliding home screen (with scroll bar) ? 2. Is Flame a non-H/W Overlay device and is it using our HAL ? 3. Can you log ANDROID_VERSION number on Flame ?
Comment 42•10 years ago
|
||
(In reply to Sushil from comment #41) > Sotaro, since you reproduced the issue on your device, I have couple of > questions: > > 1. How to reproduce that sliding home screen (with scroll bar) ? Vertical homescreen seems to set to default on master from today. > 2. Is Flame a non-H/W Overlay device and is it using our HAL ? I am not sure about Flame device's detail. But it uses the hal. > 3. Can you log ANDROID_VERSION number on Flame ? I am going to check. IIRC, it uses JB. Surface::hook_dequeueBuffer_DEPRECATED() is still used around FramebufferSurface.
Comment 43•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #42) > (In reply to Sushil from comment #41) > > Sotaro, since you reproduced the issue on your device, I have couple of > > questions: > > > > 1. How to reproduce that sliding home screen (with scroll bar) ? > > Vertical homescreen seems to set to default on master from today. If you uses relatively recent master. You can change homescreen from Settings app. It is under "Homescreen" item.
Comment 44•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #42) > > > 3. Can you log ANDROID_VERSION number on Flame ? > ANDROID_VERSION is 18. build.prop has the following. ro.build.version.sdk=18
Comment 45•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #42) > > > 2. Is Flame a non-H/W Overlay device and is it using our HAL ? > > I am not sure about Flame device's detail. But it uses the hal. flame device's manifest is the following. It get source code from caf. Therefore hal's source is also from caf. https://github.com/mozilla-b2g/b2g-manifest/blob/master/flame.xml
Updated•10 years ago
|
Whiteboard: [c=power p= s=2014.06.06.t u=] [caf priority: p2][CR 669803] → [c=power p= s=2014.06.06.t u=] [caf priority: p1][CR 669803]
Assignee | ||
Comment 47•10 years ago
|
||
I am able to reproduce this issue on v1.4 reference device in Video App in the video list frame (which is scrollable). E/HWComposer( 229): HWC layer[0]::ThebesLayer: dst=[0 0 480 800] src=[0 0 480 800] hnd=0xaa42fc40 E/HWComposer( 229): COLOR layer: bufferRect = visibleRect = [0 0 480 800] E/HWComposer( 229): HWC layer[0]::ColorLayerComposite: dst=[0 0 480 800] src=[0 0 480 800] hnd=0x0 E/HWComposer( 229): HWC layer[0]::ThebesLayer: dst=[0 0 480 800] src=[0 0 480 800] hnd=0xac12ed30 E/HWComposer( 229): ThebesLayer Layer doesn't have a gralloc buffer E/HWComposer( 229): SKIP layer: bufferRect=[0 0 0 0] visibleRect=[0 0 480 2304] E/HWComposer( 229): PrepareLayerRects failed, return true!! E/HWComposer( 229): HWC layer[1]::ThebesLayer: dst=[0 740 480 800] src=[0 0 480 60] hnd=0xabfbd560 E/HWComposer( 229): Frame rendered Since bufferRect is zero rect in case of Tiled layer so PrepareLayerRects() fails and this layer is not being added to HWC layer list and is not considered for Composition at all. The remaining 2 layers are happily composed by HWC. That's why the content is missing on scrollable Home Screen / Video list frame. So this patch is in-complete in terms of supporting Tiled layer in partial HWC Composition. Now, to handle the tiled layer, there can be 2 approaches: 1. Handle it like Color layer. For this we need to get reliable visibleRect for the tiled layer. If we see above layer configs, visibleRect=[0 0 480 2304] which is way out of bound in terms of height. So if we want to derive buffer rect from visible rect (like Color layer) at [1], gecko layer framework needs to calculate and send correct effective visible region for the tiled layer. Please explain why the visible region is too much out of bounds or is it height of entire buffer, but not tiled layer. Plus other attributes like blending, opacity, transform, etc. should be final (like Color layer) and they should not change later on because they affect composition of HWC composited layers in frame. 2. For a tiled layer, set mSize.width & mSize.height appropriately in RenderState, so we can derive buffer rect from [2]. Currently, they are 0. This is risky for v1.4. Sotaro, what is status of Bug 988511. Will we get a valid buffer for a tiled layer, once that bug is fixed ? [1]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#284 [2]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#292
Flags: needinfo?(sotaro.ikeda.g)
Comment 48•10 years ago
|
||
(In reply to Sushil from comment #47) > This is risky for v1.4. Sotaro, what is status of Bug 988511. Will we get a > valid buffer for a tiled layer, once that bug is fixed ? Bug 988511 fix is m-i now. It does not add hw composer support to tiled layers. It suppress tiled layer rendering when youtube is in fullscreen mode.
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 49•10 years ago
|
||
I verified the patch of Bug 988511 on v1.4 reference device. Full screen video playback on YouTube is now using HWC in both Landscape and Portrait modes, which should help in power numbers. So I am closing this bug, marking it as dup of Bug 988511.
Status: REOPENED → RESOLVED
blocking-b2g: backlog → ---
Closed: 10 years ago → 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•