806032 - Optimize allocation of RAM to gralloc pmem

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The framebuffer and pmem_adsp values are pretty much fixed at the moment.  However, we have lots of leeway with gralloc pmem.  The current allocation is 13MB, which is probably too high.  Because of bug 806029, I can't get a very good back-of-the-envelope estimate, but based on those faulty measurements and some others I took earlier, I think we can probably get away with 8MB.  The goal is to keep all the core gaia UI in pmem, and if web pages or unoptimized third party apps don't behave similarly, fall back on sysmem+texture upload.  Texture upload was not so hurty on adreno as on other chips, so this isn't too bad.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

With a prototype fix for bug 806029 (*cough* dirty hack), I was able to get some initial estimates.  During "normal" usage, we spike up to about 6.5MB according to pmemmon.  There are a couple of things contributing to this
 - we're not setVisible(false)ing the homescreen until late in app startup, so we end up temporarily allocating about twice as much pmem as we really need
 - the task switcher creates a surprising amount of pmem.  This may be something dumb.

While most apps are open, we stay around 2-3MB allocated.  That's a bit higher than I would expect; in the neighborhood of 4 RGBA screen-sized buffers.  We may be doing something else dumb here like keeping around a layer for the wallpaper while it's hidden.  There are three exceptions though
 - gallery.  Quickly panning through the single-image view caused pmem to spike up to 10.4MB.  There be some fixin' we can do here, but on the other hand the gallery is probably in the best position to deal with fallback teximage2d since it's literally just moving write-once textures around.
 - maps.  Opening submenus and playing with all the goodies let me spike pmem up to the 4-5MB region.  I think I know part of what's contributing to this and we can make some trade offs.
 - settings.  Surprisingly, I could spike pmem up to 4MB or so in there.  Not really sure why ...

So I'm pretty confident that 8MB is a reasonable target to shoot for.

Comment 2

[Justin Lebar (not reading bugmail)]

cjones, are you the right owner for this bug?

AIUI, this is a big memory win, so I think this should be a v1 soft-blocker (i.e., it's something we want for v1).  Am I understanding correctly?

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Yes.  Agreed.  mwu has already built a new kernel with the new params.  We just need to get the deps landed.

We can use this bug to track deploying the new pmem configuration, but there aren't any patches that need to land as part of this work.  bb+'ing this for tracking purposes sounds like a good idea to me.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

mwu, jgriffin, I'm not sure how you guys have handled this previously, but can we get new boot images pushed out to the builders for otoro and unagi which have 8MiB allocated to gralloc pmem?

Should I file any of that work as separate bugs?

We should get the new boot images linked up from the intranet as well.

Passing the baton to mwu to hand off kernels to jgriffin(?).  Since we'll be in the same room tomorrow let's try to get this knocked out quickly ;).

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

tchung: heads up that when these kernels are pushed out, QA should be on the lookout for new gfx symptoms.  The worst outcome from this change might be new crashes when there are a lot of apps open.  A less severe but also bad outcome might be general "sluggishness" of UI when there are a lot of apps open.  (I haven't hit these locally yet, though.)

Comment 6

[Tony Chung [:tchung]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> tchung: heads up that when these kernels are pushed out, QA should be on the
> lookout for new gfx symptoms.  The worst outcome from this change might be
> new crashes when there are a lot of apps open.  A less severe but also bad
> outcome might be general "sluggishness" of UI when there are a lot of apps
> open.  (I haven't hit these locally yet, though.)

cjones: Other than the stability issues and the panning performance you mentioned, is there gfx symptoms such as content layout rendering or graphical glitches that this work would affect?   (i ask this cause we saw problems when they refactored fennec)

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Not really, but of course anything is possible ;).

Comment 8

[Michael Wu [:mwu]]

Gonna close this bug since the new kernels are distributed, but a FOTA probably needs to be pushed to get this out to all dogfooders.