I dig a bit more to find reason of this behavior and in case someone
will have similar problem I'd like to summarize my findings:
This is original allocator dump:
> D/Blockx.GameController(900): Surface created
> E/SurfaceFlinger(577): not enough memory for layer bitmap size=1642496
> (w=480, h=854, stride=480, format=1)
> D/MemoryDealer(577): LayerBitmap (0x2e9350, size=8388608)
> D/MemoryDealer(577): 0: 002e9388 | 0x00000000 | 0x0003E000 | F
> D/MemoryDealer(577): 1: 00373ab0 | 0x0003E000 | 0x00191000 | A
> D/MemoryDealer(577): 2: 00373b78 | 0x001CF000 | 0x00191000 | A
> D/MemoryDealer(577): 3: 0028bd40 | 0x00360000 | 0x0003E000 | F
> D/MemoryDealer(577): 4: 002ce748 | 0x0039E000 | 0x00059000 | A
> D/MemoryDealer(577): 5: 002ce7c0 | 0x003F7000 | 0x00059000 | A
> D/MemoryDealer(577): 6: 00374bb0 | 0x00450000 | 0x00191000 | A
> D/MemoryDealer(577): 7: 00375ec8 | 0x005E1000 | 0x00059000 | A
> D/MemoryDealer(577): 8: 00377c30 | 0x0063A000 | 0x00059000 | A
> D/MemoryDealer(577): 9: 00377d50 | 0x00693000 | 0x0016D000 | F
> D/MemoryDealer(577): size allocated: 6385664 (6236 KB)
Surface views allocates two buffers (layers), if we run in
compatibility mode (upscalling) each surface view allocates 4 buffers
(two for physical window and two for emulated one), so block 1, 2 and
4, 5 are buffers allocated by first surface view, surprisingly
physical buffers are not affected by setPixelFormat and on emulator
allocates RGBA32 pixels (854 * 480 * 4 = 0x191000). Blocks 4 and 5 are
logical buffers in RGB565 format (320 * 569 * 2 = 58E80 aligned
59000).
8MB hardlimit comes from VRamHeap.cpp (video memory heap manager) and
from SurfaceFlinger (odd that this is defined in two different
places):
VRamHeap.cpp:
53 /*
54 * Amount of memory we reserve for surface, per client in PMEM
55 * (PMEM is used for 2D acceleration)
56 * 8 MB of address space per client should be enough.
57 */
58 static const int PMEM_SIZE = int(8 * 1024 * 1024);
SurfaceFlinger.cpp:
370 // create the surface Heap manager, which manages the heaps
371 // (be it in RAM or VRAM) where surfaces are allocated
372 // We give 8 MB per client.
373 mSurfaceHeapManager = new SurfaceHeapManager(this, 8 << 20);
First limit is applied to PMEM allocator second to standard software
allocator (which I suspect is used on emulator):
119 if (dealer == NULL) {
120 // always try h/w accelerated memory first
121 if (global_pmem_heap) {
122 const sp<PMemHeap>& heap(mPMemHeap);
123 if (dealer == NULL && heap != NULL) {
124 dealer = new MemoryDealer(
125 heap->createClientHeap(),
126 heap->getAllocator());
127 }
128 }
129 }
130
131 if (dealer == NULL) {
132 // return the ashmem allocator (software rendering)
133 dealer = new MemoryDealer(mClientHeapSize, 0,
"SFNativeHeap");
134 }
mPMemHeap is created with PMEM_SIZE limit and mClientHeapSize is
passed as argument to SurfaceHeapManager constructor.
On real device surfaces with GPU memory type should be allocated from
different pool (namly GPU allocators), so answer to my original
question is probably no, on real devices this limit will be different
since surfaces are allocated from different heaps.
--
Bart (arcone1) Janusz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
