This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mali 400 - Video memory available

Note: This was originally posted on 6th September 2012 at http://forums.arm.com

Hello,

We are developping a 3D game on a platform that has a Mali-400 MP4. I have a question about the video memory really available: the global chip has about 1go of memory (we can do 11 new of 100Mb each before to get a NULL pointer) but the memory available for graphics data seems quite low. Here is the code we used to check the available memory for both texture and VBO (tested seperatly):

// Vbo memory test.
    while (CheckGLError("Flush before VBO") == true); // Flush all previous errors.
    int const nSizeVBuffer = 512*1024;
    static char pDataVBuffer[nSizeVBuffer];
    int nNbVBO = 0;
    do
    {
        GLuint nVBufferID = 0;
        glGenBuffers( 1, &nVBufferID );
        glBindBuffer( GL_ARRAY_BUFFER, nVBufferID);
        glBufferData( GL_ARRAY_BUFFER, nSizeVBuffer, pDataVBuffer, GL_STATIC_DRAW);

        nNbVBO++;
        CPrintf::AddTextFile("Generate VBO %d (%d)\n", nNbVBO, nVBufferID);
    } while (CheckGLError("VBO Loading") == false);

// Here we "transfer" about only 70Mbytes before the GLerror.

// Texture memory test.
    while (CheckGLError("flush before Textures") == true); // Flush all previous errors.
    int const nW = 256;
    int const nH = 256;

    static char pTabPixel[nW * nH * 4];
    int nNbTexLoaded = 0;
    do
    {
        GLuint nTexId;

        glGenTextures ( 1, &nTexId);
        glBindTexture ( GL_TEXTURE_2D, nTexId);

        CPrintf::AddTextFile("Generate texture %d (%d)\n", nNbTexLoaded, nTexId);

        glTexImage2D ( GL_TEXTURE_2D, 0, GL_RGB, nW, nH, 0, GL_RGB, GL_UNSIGNED_BYTE, pTabPixel);

        nNbTexLoaded++;

    } while (CheckGLError("Texture loading") == false);

// Here we "transfer" about only 90Mbytes before the GLerror.

So, in the best case it seems we have less than 100Mb of memory available for texture, vbo and ibo.

Does it seems a "normal" behavior or do we miss something? Could it be specific to the platform we are developping on (don't ask which one I cannot say)? Is there any way to have more "graphic" memory on Mali GPU?

Thank you in advance for your answers....

Regards,

Chris Varnsverry over 11 years ago

Note: This was originally posted on 6th September 2012 at http://forums.arm.com

Hi Jgl,

Thanks for your question. In platforms where the Mali400 GPU is using main memory, the maximum amount of memory available to it is set as a parameter when building the kernel driver, and so is platform/build specific.

Are you building the driver yourself, either externally or as part of the kernel build? If so I can give direction on how to increase the amount of memory available to the GPU.

Thanks
Chris
Cancel
Up 0 Down

Cancel
Jean-Georges Levieux over 11 years ago

Note: This was originally posted on 7th September 2012 at http://forums.arm.com

Hello,

Thank you for the answer.

Unfortunately we are not building the driver, it's done by the vendor and linked dynamically at the launch of the application (we do not even have the lib files and we cannot change them by any way).

Just to have an additionnal information to talk with the vendor: does it means that when memory is allocated for the GPU it's not more available for the system (CPU)? So, if you need a lot of system memory for CPU usage you have to limit the GPU memory allocated in the driver? The memory cannot be shared as it's possible on some other GPU/System?

Regards,
Cancel
Up 0 Down

Cancel
Chris Varnsverry over 11 years ago

Note: This was originally posted on 7th September 2012 at http://forums.arm.com

Hi Jgl,

When using OS memory, I am told the driver is essentially malloc-ing system memory up to the limit specified, but this is still classed as system memory, so it is still available to the system (CPU). In this case, there is nothing stopping a CPU application from malloc-ing all available system memory and resulting in the GPU having no available memory, and GLES returning an out-of-memory error. So while it's possible to increase the maximum allowed memory usage in the driver, this does not guarantee that that amount of memory is actually available (setting your maximum to 1GB on a 1GB system will allow mali to malloc as much as it wants, but you can safely assume 1GB won't be available).

There is an alternative method called dedicated memory, where you specify an amount of memory that is reserved for mali, say 128MB, which you would make invisible to the system memory, So the kernel would see only 896MB. You can do this in addition to OS memory, so define 128MB dedicated and 128MB OS memory, with a preference on using the dedicated memory first. This means that mali has access to a total of 256MB, but only 128MB is guaranteed.

I hope this answers your question.
Chris
Cancel
Up 0 Down

Cancel