This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Out of Control Memory allocation using OMAP:DSS2

I am experiencing a seemingly out-of-control memory consumption by the gl kernel modules when using DSS.  When I noticed the system hung I stopped my application with gdb (running on the target) and the free memory reported by top was around 16mb (128mb total).  I then ran rc.pvr restart and the free memory jumped back up to 78mb.  I am using the v2.6.32_OMAPPSP_03.00.00.04 tagged linux from (http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary) along with the gfx_rel_es3.x drivers from OMAP35x_Graphics_SDK_setuplinux_3_01_00_02.bin  along with a 640x480 lcd panel on custom OMAP3530CUS based hardware.

My question is what commands or type of commands cause the most memory allocation and how can this be controlled?  Any hints as to what things can be tried or avoided would be greatly appreciated.

Thanks,

Ken

Here is a backtrace:

^C
Program received signal SIGINT, Interrupt.
0x40371c3c in ioctl () from /lib/libc.so.6
(gdb) Quit
(gdb) bt
#0  0x40371c3c in ioctl () from /lib/libc.so.6
#1  0x403ec9f0 in PVRSRVBridgeCall (hServices=<value optimized out>,
    ui32FunctionID=3223086917, pvParamIn=<value optimized out>,
    ui32InBufferSize=<value optimized out>, pvParamOut=0xbe88f778,
    ui32OutBufferSize=8)
    at /home/prabu/gfxsdkcreate/builder_09/ddkbuild/ti_references/sources/GFX_Linux_DDK/src/eurasia/s
ervices4/srvclient/env/linux/common/pvr_bridge_u.c:188
#2  0x403ec1d8 in PVRSRVEventObjectWait (psConnection=<value optimized out>,
    hOSEvent=<value optimized out>)
    at /home/prabu/gfxsdkcreate/builder_09/ddkbuild/ti_references/sources/GFX_Linux_DDK/src/eurasia/s
ervices4/srvclient/env/linux/common/osfunc_um.c:307
#3  0x403ef444 in PVRSRVPollForValue (psConnection=0x36, hOSEvent=0xf,
    pui32LinMemAddr=0x4113031c, ui32Value=1, ui32Mask=4294967295,
    ui32Waitus=1000, ui32Tries=913)
    at /home/prabu/gfxsdkcreate/builder_09/ddkbuild/ti_references/sources/GFX_Linux_DDK/src/eurasia/s
ervices4/srvclient/common/resources.c:85
#4  0x401b4b1c in HardwareTextureUpload (gc=0x0, psTex=0x5a35d10,
    ui32OffsetInBytes=0, psLevel=0x5a81c38) at texdata.c:1535
#5  0x401b56fc in TranslateLevel (gc=0x59a2860, psTex=0x200000, ui32Face=0,
    ui32Lod=0) at texdata.c:2155
#6  0x401b7628 in TextureMakeResident (gc=0x0, psTex=0x5a35d10)
    at texmgmt.c:1010
#7  0x401ba004 in SetupTextureState (gc=0x59a2860) at texmgmt.c:2497
#8  0x401c4a5c in ValidateState (gc=0x59a2860) at validate.c:4211
#9  0x40193554 in glDrawArrays (mode=4, first=0, count=6) at drawvarray.c:2254
#10 0x000a8094 in GRL2_DrawFontList (list=0x11bc064) at GRL2/GRL2_util.c:317
#11 0x0000ef5c in UpdateScreen () at AFS/AFS_event.c:232
#12 0x0000f188 in EventLoop () at AFS/AFS_event.c:123
#13 0x000f58ec in main (argc=<value optimized out>, argv=0xbe88fdb4)
    at AFS/AFS_main.c:104

  •   Texture maps and Frame Buffer Objects (FBOs) can cause OpenGL ES to allocate large internal buffers.  Look at the sizes of the images you are passing in calls to glTexImage2D or glFramebufferTexture2D.

    This article explains the use of these buffers:

    http://wiki.davincidsp.com/index.php/Render_to_Texture_with_OpenGL_ES

    Regards, Clay