• Locked Locked
  • Replies 16 replies
  • Subscribers 136 subscribers
  • Views 18287 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Many Issue with Mali 400 on A10 (Linux)

Piyush Verma
Note: This was originally posted on 17th August 2012 at http://forums.arm.com

Hi,

I am facing many problems with Mali 400. One of the big issue is lib is close source so can't change anything.

I am in advance stage of product development but stuck with many issues.

Point 1.

I was using Ericsson Texture Compression Mipmap Example and trying to work with normal RGBA texture.

Here is my load texture code.

/* Load just base level texture data. */
GL_CHECK(glGenTextures(1, &textureID));
GL_CHECK(glBindTexture(GL_TEXTURE_2D, textureID));
unsigned char *textureData = NULL;
Texture::loadData(texturePath.c_str(), &textureData);
    
GL_CHECK(glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 256, 256, 0, GL_RGBA, GL_UNSIGNED_BYTE, textureData));    

Here it just render a black area.

Just by referring RotoZoom program and with hit and try I fogure out it work if I add.

/* Set texture mode. */
GL_CHECK(glGenerateMipmap(GL_TEXTURE_2D));

after glTexImage2D.

Is glGenerateMipmap must to use texture ?
besides there is not any sample program which load basic rgba texture.

Point 2.
Besides with 2 or 3 test system give sigmentation fault continuously. Even is workable program.

Same program which was working before not work now and can work again on system restart.

Point 3.
EGLSwapbuffer is consuming 50% CPU. & I can't find any way to render directly to frame-buffer. Mali document say it's platform specific.
I can't understand FB interface is fix in all linux how come it could be platform specific ?.
Every body no most of vendor not support for anything like this.

Point 4.
http://www.arm.com/products/multimedia/mali-graphics-hardware/mali-400-mp.php
here mention 30M tri/s and up to 1.1G pix/s at 275MHz.

Correct me if I am wrong 1.1G Pix is filling pixels of screen with color or texture.

1.1 * 1000 *1000 *1000 / 1920 / 1080 / 60 = 8.84 Layers

if means if I render full hd @ 60 FPS I should be able to render full screen 8.84 times.

I am using a simple triangle program which is filling the screen and rendering 8 times in one round. then performance is dropping to 14fps.

Means 4 times slower than speq. where other points gpu is running on 320 Mhz not on 275 Mhz.

Point 5.

A very simple triangle program is not working in GLES1 so I am bound to use only GLES2.
As many places internet mention GLES1 is faster than GLES2.
There is not any sample program for GLES1. and document talk about gles1 simulator but there is not any gles1 simulator on mali website.


Point 6.

What is the process to get Mali 400 DDK Source.
Is it possible to get even after spending some money ?


Any clarification in above points can help us.

Thanks in Advance.


Regards

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


    Like most embedded GPUs Mali only starts rendering when you call eglSwapBuffers - it's more power efficient to buffer things up and submit it all to the hardware in one big batch, so what you are actually doing is forcing a big gap between your GL commands and the hardware starting.

    The following is far more common

    while( true )
        Do game behavior update
        Call glClear ( COLOR | DEPTH | STENCIL )
        Do all GL commands according to the game behavior update
        Call eglSwapBuffers

    Remember eglSwapBuffers is asynchronous and doesn't actually swap anything, it just tells the driver "I'm done with this window surface". The actual window system update happens "later" under driver control.


    Hello, thank you for your reply.

    If I well understand: the eglSwapBuffers take care of the GL commands I do, pass it to the GPU that will handle these command asynchronously. Then, if the next time I call eglSwapBuffers, the previous list of gl command is not yet finish to draw by the GPU, eglSwapBuffers will wait until it's finished ; this is why we can have a big amount of time consumed by eglSwapBuffers.

    Is that right?

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


    Like most embedded GPUs Mali only starts rendering when you call eglSwapBuffers - it's more power efficient to buffer things up and submit it all to the hardware in one big batch, so what you are actually doing is forcing a big gap between your GL commands and the hardware starting.

    The following is far more common

    while( true )
        Do game behavior update
        Call glClear ( COLOR | DEPTH | STENCIL )
        Do all GL commands according to the game behavior update
        Call eglSwapBuffers

    Remember eglSwapBuffers is asynchronous and doesn't actually swap anything, it just tells the driver "I'm done with this window surface". The actual window system update happens "later" under driver control.


    Hello, thank you for your reply.

    If I well understand: the eglSwapBuffers take care of the GL commands I do, pass it to the GPU that will handle these command asynchronously. Then, if the next time I call eglSwapBuffers, the previous list of gl command is not yet finish to draw by the GPU, eglSwapBuffers will wait until it's finished ; this is why we can have a big amount of time consumed by eglSwapBuffers.

    Is that right?

    Regards,
Children
No data