982972 - investigate using RT priority in compositor on gonk

Status: RESOLVED WONTFIX

(Core :: Graphics, defect, P2)

Description

[Ben Kelly [:bkelly, not reviewing]]

As discussed in bug 980027 we would ultimately like to move the compositor to RT priority 1 if possible.  This is mainly driven by the improvements we see in the profiles when the compositor is running at RT1.

Once bug 980027 lands this can be achieved by setting this pref in b2g/app/b2g.js:

  pref("hal.gonk.compositor.rt_priority", 1);

Before doing that, however, we must do the following:

1) Verify that audio and video playback do not skip.  This will require extensive testing and is the main work to be done in this bug.
2) Fix the buri framebuffer driver to work well with compositor at RT 1.  This is bug 982968.

In order to perform (2) it would be helpful to have a set of use cases where we have had difficulty with audio/video skipping in the past.

Any change here should have review from both gfx and media.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Comment 0 should say "In order to perform (1)" we would like to know what media use cases have been problematic in the past.

Comment 3

[Mason Chang [Inactive] [:mchang]]

After chatting with a few folks, we should set the Compositor priority to RT 1. As bkelly said in comment 0, audio should be the only thing with a higher priority. Acceptance criteria will be testing on a tarako and flame. As long as audio doesn't skip on a tarako + flame, we can raise the compositor priority.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Mason Chang [:mchang] from comment #3)
> Acceptance criteria will be testing on a tarako and flame. As long
> as audio doesn't skip on a tarako + flame, we can raise the compositor
> priority.

I'd recommend only doing this for JB/KK and exclude ICS devices in order to avoid bug 982968.  This would mean you would not need to test tarako as well.

Comment 5

[Mason Chang [Inactive] [:mchang]]

Attachment: Compositor Scheduling Delays w/ Normal Priority

Comment 6

[Mason Chang [Inactive] [:mchang]]

Attachment: Compositor Scheduling Delays w/ RT Priority 1

For Project Silk, we need to raise the compositor thread priority to RT 1. Just attaching the data.

Comment 7

[Mason Chang [Inactive] [:mchang]]

I just tried running a prototype version of Silk with the Compositor thread priority to RT 1. Even at nice -2, we checkerboard much more. With RT 1, cold load times skyrocket, after 10 seconds the settings app wouldn't load. While we can scroll smoothly, we scroll into blank because we checkerboard. In addition, with Silk, we then start to notice delays in touch responsiveness, even though the touch input is being processed off main thread. RT 1 might be too high, not closing this bug yet, but might not be valid. All tests were done on a Nexus 4. For comparison, android has a nice value for the compositor at -4, with "Urgent" display being at -8. Audio is at -19.

Comment 8

[Sotaro Ikeda [:sotaro]]

Before using RT, it seems better to add Bug 1038134 as one use case for checking.

Comment 9

[Mason Chang [Inactive] [:mchang]]

Closing as wont fix from comment 7. Too many other things take too long to load on a flame.