[8.9" Kindle Fire HD Android Development] jonasl:
TL;DR

There's a link to a flashable zip below, that will give you improved performance in certain situations such as the launcher.

Great work on the ROM!

However, the graphics performance in certain use cases can be better; specifically the hardware composer (HWC) could be used more often and more efficiently. Since I know a thing or two about this topic I felt like sharing some information as well as an improved version of the latest release.

One of the most common heavy scenarios for the composer is the launcher with status bar pulled down. That's because there are multiple big (full screen or even larger in case of wallpaper) surfaces to compose, including several blends.

As of cm-10.1-20130812-UNOFFICIAL-jem.zip, most of the composition for the launcher is done on the fairly low performing GPU. Apart from the GPU not being terribly efficient at composition tasks like this, using it for it means context switching away from rendering of the next frame (ie more things want to use the GPU = bad performance). This is where the hardware composer (HWC) comes in. It offloads the composition to dedicated hardware. OMAP's overlay engine is called DSS and there is also a 2D blitter on the OMAP 4470 SoC called GC320 (accessed through bltsville mentioned in the OP). The HWC module uses both in different scenarios.

Ideally we want to use DSS all the time, but it can only handle 4 layers, not all pixel formats, certain scalings and other things. It's also limited by a certain type of memory.

The 2D blitter has other constraints; memory alignment of surfaces to blend, scaling and rotation.

This is information that anyone can gather from code on omapzoom.

At any given time; this command will show the current state of the composer (output shortened):

$ adb shell dumpsys SurfaceFlinger
Hardware Composer state (version 1000000):
mDebugForceFakeVSync=0
Display[0] : 1920x1200, xdpi=254.000000, ydpi=254.000000, refresh=16684463
numHwLayers=4, flags=00000000
type | handle | hints | flags | tr | blend | format | source crop | frame name
------------+----------+----------+----------+----+-------+----------+---------------------------+--------------------------------
GLES | 40024ee0 | 00000000 | 00000000 | 00 | 00100 | 00000002 | [ 1055, 434, 2975, 1524] | [ 0, 38, 1920, 1128] com.android.systemui.ImageWallpaper
GLES | 4170fe88 | 00000000 | 00000000 | 00 | 00105 | 00000005 | [ 0, 38, 1920, 1128] | [ 0, 38, 1920, 1128] com.cyanogenmod.trebuchet/com.cyanogenmod.trebuchet.Launcher
GLES | 40c4c2e8 | 00000000 | 00000000 | 00 | 00105 | 00000005 | [ 0, 0, 1920, 1200] | [ 0, 0, 1920, 1200] StatusBar
HWC | 41626cc8 | 00000003 | 00000000 | 00 | 00100 | 00000005 | [ 0, 0, 1920, 72] | [ 0, 1128, 1920, 1200] NavigationBar

Your output will be slightly different, this is an example. For best performance, we don't want to see any GLES layers (handled by GPU); the more HWC the better. The hint column tells you if DSS (00000001) or blitter (00000003) handled the HWC layer.

The relevant code was written for the Kindle UI running on ICS; it's not well tuned for AOSP/JB on OMAP. Let's make some simple modifications to try to change that!

#1 The wallpaper format in this case is RGBX_8888 (00000002). It's fairly common that it becomes this, but depends on how you've used the system and which wallpapers you've set. It could be 00000005 already on your device.

RGBX_8888 is not handled by DSS, so we tell the system to just request an opaque surface by default. The GPU driver will return a 00000005 surface that the system likes better. This change increases the chance that DSS can handle the wallpaper, and if not, makes it more blitter friendly.

frameworks/base:

diff --git a/core/java/android/service/wallpaper/WallpaperService.java b/core/java/android/service/wallpaper/WallpaperService.java
index 6d5705d..e1f2149 100644
--- a/core/java/android/service/wallpaper/WallpaperService.java
+++ b/core/java/android/service/wallpaper/WallpaperService.java
@@ -186,7 +186,7 @@ public abstract class WallpaperService extends Service {

final BaseSurfaceHolder mSurfaceHolder = new BaseSurfaceHolder() {
{
- mRequestedFormat = PixelFormat.RGBX_8888;
+ mRequestedFormat = PixelFormat.OPAQUE;
}

[MENTION=439709]override[/MENTION]

Since we have some pretty severe memory constraints, the wallpaper can't be too big. This change also needs the kernel patch below. DSS needs memory called TILER1D, but we can't reserve too much. Let's limit the wallpaper width to 2100, which still looks OK.

device/amazon/jem:

diff --git a/overlay/frameworks/base/core/res/res/values/config.xml b/overlay/frameworks/base/core/res/res/values/config.xml
index 8dea2bf..63b2bd2 100644
--- a/overlay/frameworks/base/core/res/res/values/config.xml
+++ b/overlay/frameworks/base/core/res/res/values/config.xml
@@ -214,4 +214,5 @@
<!-- Maximum number of supported users -->
<integer name="config_multiuserMaximumUsers">8</integer>

+ <integer name="config_wallpaperMaxWidth">2100</integer>
</resources>

We should also increase the TILER1D allocation so that wallpaper, launcher, navigation bar and expanded status bar fits.

diff --git a/arch/arm/mach-omap2/board-bowser-panel.c b/arch/arm/mach-omap2/board-bowser-panel.c
index f1d4197..4aa917e 100644
--- a/arch/arm/mach-omap2/board-bowser-panel.c
+++ b/arch/arm/mach-omap2/board-bowser-panel.c
@@ -412,9 +412,29 @@ static struct platform_device *bowser_devices[] __initdata = {

#endif /*CONFIG_BACKLIGHT_LP855X*/

-//Allocate 27 MB for TILER1D slot size for WUXGA panel on JEM, total of 54 MB of TILER1D
+/*
+ Allocate 34 MB for TILER1D slot size for WUXGA panel on JEM, total of 68 MB of TILER1D
+
+ These values are based on stock AOSP tablet UI home screen. JB needs more than ICS
+ because behavior of pulled down status bar has changed.
+
+ Rough calculations:
+
+ Wallpaper:
+ 15120.00 KiB | 2000 (2016) x 1920
+
+ Launcher:
+ 8460.00 KiB | 1920 (1920) x 1128
+
+ StatusBar:
+ 9000.00 KiB | 1920 (1920) x 1200
+
+ NavigationBar:
+ 540.00 KiB | 1920 (1920) x 72
+
+ */
static struct dsscomp_platform_data dsscomp_config_wuxga = {
- .tiler1d_slotsz = ( SZ_16M + SZ_2M + SZ_8M + SZ_1M ),
+ .tiler1d_slotsz = ( (15 * SZ_1M) + (9 * SZ_1M) + (9 * SZ_1M) + (1 * SZ_1M) ),
};

#if defined(CONFIG_FB_OMAP2_NUM_FBS)

With a better pixel format for the wallpaper of limited size, and increased TILER1D allocation, DSS can now handle all surfaces when using the launcher:

Hardware Composer state (version 1000000):
mDebugForceFakeVSync=0
Display[0] : 1920x1200, xdpi=254.000000, ydpi=254.000000, refresh=16684463
numHwLayers=4, flags=00000000
type | handle | hints | flags | tr | blend | format | source crop | frame name
------------+----------+----------+----------+----+-------+----------+---------------------------+--------------------------------
HWC | 400621c8 | 00000001 | 00000000 | 00 | 00100 | 00000005 | [ 90, 434, 2010, 1524] | [ 0, 38, 1920, 1128] com.android.systemui.ImageWallpaper
HWC | 40062f08 | 00000001 | 00000000 | 00 | 00105 | 00000005 | [ 0, 38, 1920, 1128] | [ 0, 38, 1920, 1128] com.cyanogenmod.trebuchet/com.cyanogenmod.trebuchet.Launcher
HWC | 400a0410 | 00000001 | 00000000 | 00 | 00105 | 00000005 | [ 0, 0, 1920, 1200] | [ 0, 0, 1920, 1200] StatusBar
HWC | 40b5dc40 | 00000001 | 00000000 | 00 | 00100 | 00000005 | [ 0, 0, 1920, 72] | [ 0, 1128, 1920, 1200] NavigationBar

The result is that swiping is now equally smooth in all orientations (not the case originally due to internals I don't have time to explain in detail), and the status bar expands more smoothly. Try it at home screen and in app drawer in all 4 rotations. Launcher is not the only scenario helped by this but is the most obvious one. Any scenario with big surfaces to blend will be improved if it was limited by the TILER1D allocation.

The downside is a few less MBs of RAM available to Android, but is hardly noticeable.

zip: https://dl.dropboxusercontent.com/u/6778890/cm-10.1-20130812-jonasl-jem.zip

Flash, wipe cache, reboot. Based on cm-10.1-20130812-UNOFFICIAL-jem.zip with the mentioned changes.

I don't plan to maintain or support this version. It's not tested for stability. Changed values may need further tuning. It does however work well for me (tm). I hope these ideas will get picked up by others, but since I put it together for my own use I thought I might as well share.