How to check Tiler Memory availability on OMAP4

• The default configuration for Tiler Memory availability on OMAP4 baseports.
• Is the issue being faced because of a shortage in Tiler memory?
• If yes, how can the configuration be changed?

OMAP4 has 128 MB of Tiler memory. It cannot be increased.

This issue is likely a TILER allocation failure. What Android release are you using?Could you provide the logcat output. Could you also give the use cases: Codec, dimensions and number of decoders

• How do I know if there is any other application which is using the available Tiler memory?

Tiler memory is used for:

2-D and 1-D buffers for graphics processing

2-D Buffers for Decoded frames

The number of decoder buffers used depends on the profile/level and dimensions.

For H.264 Baseline profile: number of buffers = N+3, where N = number of reference frames.

Number of TILER buffers allocated can be obtained as follows in ICS, from adb shell:

 # mount -t debugfs none /sys/kernel/debug

# cat /sys/kernel/debug/tiler/map/1x1

Hi,

Thanks for the reply. I ran a few tests and checked the Tiler availability.

This is the configuration that I am using:

Android release: 4AI.1.5

Number of decoders: 2 instances of H264 decoder. (MPEG2 decoder is also used in some cases).

Profile: I use clips of all profiles - Baseline, Main and High

Resolution: 1280 x 720

Number of Reference frames: 1 to 3 (depending on the clips used)

Number of buffers requested by the decoder:

• 5 buffers, for 1 reference frame. This is what the decoder requests. I thought this would be 4, but it is 5.
• 7 buffers, for 3 reference frames.
• Sometimes I use 2 instances of MPEG2, which requires 8 buffers per channel.

I am testing this app on a custom board as well as Blaze-tablet.

SURFACE FLINGER DETAILS

I checked the initial amount of memory that is in use by SurfaceFlinger using the command 'dumpsys SurfaceFlinger'.

Theses checks were made, right after boot.

On Blaze-Tablet

When screen is locked: Surface Flinger uses around 18 MB.

When screen is unlocked: Surface Flinger uses around 12 MB.

On Custom board

Surface Flinger uses around 20 MB.

It looks like this is leading to memory constraints in the system.

TILER CONFIGURATION

I can see the following sizes of 2x2 Tiler allocations:

CUSTOM BOARD

The default allocations after boot:

1) 128 x 23

2) 32400k

3) 32400k

My application takes up

4) 22 x 13 - between 5 and 9 buffers per channel depending on the clips I use.

Blaze Tablet

The default allocations after boot:

1) 64 x 24

2) 16000k

3) 16000k

My application takes up

4) 22 x 13 - between 5 and 9 buffers per channel depending on the clips I use.

PROBLEM:

Since the default Tiler memory usage on the custom board is high, I get memory allocation failures from the 13^th buffer (inclusive of 2 channels – 1408 x 832) onwards.

The limit for blaze-tablet is higher, though.

QUESTION:

• Is there any way to find out the exact applications that are using each of the allocated Tiler buffers?
• What are the default applications that use up Tiler memory?
• Does the screen size have any impact on the usage? – 720 display v/s 1080 v/s VGA, etc.
  • The screen size of my custom board is 1280 x 720.
  • The display interface used is HDMI.
  • Could the difference in interface be resulting in the use of some additional driver which is leading to the difference in Tiler memory usage?

Regards

Anoop

Hi Anoop,

You can check the tiler memory usage by using the following sysfs command. cat /d/tiler/map/2x2

The frame buffer is allocated in Tiler space by default on ICS releases. Display buffers used by decoder and also encoder buffers are allocated in tiler space.

Definitely, the resolution of the panel would result in higher allocations in tiler space for frame buffer.

Thanks & Best Regards,

Venkat

Venkat,

The memory value that I have mentioned have been obtained from the command suggested by Paul. I believe both the commands result in the same memory map display. It would be good if you can point me towards how i can find out about applications / drivers that are using the Tiler memory at any given point of time.

-Anoop

Anoop,

Blaze Tablet

The default allocations after boot:

1) 64 x 24

2) 16000k

3) 16000k

1) is a 2-D buffer, 2) and 3) are 1-D buffers. They are all used for display/graphics processing.

The 64x24 2-D buffer represents blocks of size 64x64 bytes each - total buffer size is 6 MB. The other two buffers are 1-D buffers of 16 MB each.

The total Tiler memory available is 128 MB. At boot time 38 MB is already taken up for display (with above 3 buffers). So, you only have 90 MB vailable for decoding.  2-D buffers have a 4KB alignment constraint resulting in "wasted padding" between buffers, which you must have noticed in the TILER map. So, you have effectively less than 90MB available.

As you mentioned, some streams use more buffers than reference frames indicate. This is because the decoder calculates buffers based on profile and level - it is a worst case number. It does not calculate based on the number of reference frames in the SPS header. 

If your App can determine the number of reference frames before the strream is sent to the ducati (by parsing the SPS header), you can set the number of reference frames using OMX_SetParameter with OMX_IndexParamVideoAvc, and set nRefFrames.

Paul,

Thanks for the reply.

So, considering the allocations on my custom board, which goes like this

1) 128 x 23

2) 32400k

3) 32400k

The initial Tiler memory getting used is 63.28 MB + 11.5 MB = 74.78 MB ~ 75 MB. I am left with 53 MB for decoder buffers.

Since I need to use 5 720p buffers for one clip, this results in 10 720p buffers. 1 720p buffer will be (4096 * 832 *1.5) = 4.875 MB, this includes the "wasted padding". So, this implies, I am just about hitting the limit for Tiler memory with 10 buffers. Anything beyond that cannot be allocated.

This is the reason for the inability to run multiple instances of decoder in case the number of reference frames are higher.

What this also means is that on blaze-tablet, I can get a maximum of 18 720p buffers for decoding, which implies a reference frame limit of 4 for High Profile.

Btw, I am actually configuring the decoder based on number of reference frames now. But, I had assumed that the number of buffers required where (N*2 + 1), where N is the number of reference frames. This is the behavior I have noticed when the maximum supported profile is set to High Profile.

• Will the number of buffers required change to N+3, if I set the max supported to profile to Baseline. 
• If yes, can I still go ahead and provide High Profile content as input? Or will the decoder block this profile?

Regards 

Anoop