EGL issue with OpenGL ES 2.0 on OMAP3530

This topic contains 17 replies, has 4 voices, and was last updated by  CarlosSarria 8 years, 1 month ago.

Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • #29948

    jrshah
    Member

    Hello everyone,

    I am trying to run my OpenGL ES 2.0 application on OMAP3530 platform. As the platform has PowerVR SGX core, I have run into some EGL failure. The EGL functions and my OpenGL ES 1.1 application works all right. However, as soon I try to run OpenGL ES 2.0 application, the EGL Create Context function starts to fail with EGL_BAD_ALLOC error. The only change in my usage of EGL in both scenarios is that for OpenGL ES 1.1, I do not specify EGL_RENDERABLE_TYPE configuration parameter and use the default. For OpenGL ES 2.0 case, I specify the EGL_RENDERABLE_TYPE as EGL_OPENGL_ES2_BIT. As a result, EGL initialization, configuration selection and surface creation succeeds. But the eglCreateContext function fails with error code 0x3003 – EGL_BAD_ALLOC. There is a single context attribute specified which is EGL_CONTEXT_CLIENT_VERSION with value 2 (default is 1 for OpenGL ES 1.1).

    I just do not know why the bad allocation is causing failure. When everything is working fine for EGL with OpenGL ES 1.1, it should work all right for OpenGL ES 2.0 as well as the same EGL API is used but with slightly different parameters. The Linux kernel is 2.6.29. Any help is greatly appreciated. Thanks.     

    – J R Shah

    #33433

    prabindh
    Member

    For the right usage, you can look for examples in the Graphics SDK itself, or in the sgxperf samples online at,

     

     

    If you can post your code, we can take a look,

     

    Also, run eglinfo and ensure that there is nothing suspicious in there.

     
    #33434

    jrshah
    Member
    My EGL configuration parameters are:

    EGLint pi32ConfigAttribs[5];
    pi32ConfigAttribs[0] = EGL_SURFACE_TYPE;
    pi32ConfigAttribs[1] = EGL_WINDOW_BIT;
    pi32ConfigAttribs[2] = EGL_RENDERABLE_TYPE;
    pi32ConfigAttribs[3] = EGL_OPENGL_ES2_BIT;
    pi32ConfigAttribs[4] = EGL_NONE;

    Also, my EGL context attributes are the minimal defaults:

    EGLint ai32ContextAttribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };

    As a result, the function eglCreateContext () is failing with EGL_BAD_ALLOC error. Normally, EGL functions fail
    due to improper specification of some configuration parameter. For that, EGL_BAD_CONFIG error is normally
    encountered. However, this EGL_BAD_ALLOC failure scenario is very strange and difficult to track down. Has
    anybody seen such an error before? I am very unsure about the cause of this failure as the EGL functions are
    working all right with OpenGL ES 1.1 case.

    - J R Shah



    #33435

    jrshah
    Member

    From where can I get the working PowerVR libraries that are tested and known to work correctly with OpenGL ES 2.0 and Linux kernel 2.6.29 on the OMAP3530 platform? Thanks.

    #33436

    prabindh
    Member

    What version of the OMAP3530 EVM Graphics SDK are you using ? and what does eglinfo output ?

    #33437

    jrshah
    Member

    The eglInfo produces the following output:

    egl error ‘EGL_NOT_INITIALIZED’ (0x3001) Unable to initialise egl

     

    #33438

    prabindh
    Member
    What version of the Graphics SDK are you on ? We have been releasing binaries/patches for Beagleboard from 06 release onwards.

     

    Is it possible that you are “really” running out of memory in your system ?

     
    #33439

    jrshah
    Member

    The SDK version is 3_00_00_06.

    #33440

    jrshah
    Member

    I do not think that my system is going into an OUT OF MEMORY situation. The same application works fine if I limit myself to OpenGL ES 1.1 only. As soon as I configure EGL to be OpenGL ES 2.0, it simply gives EGL_BAD_ALLOC for eglCreateContext() API. Here, the only difference in EGL usage for both versions of OpenGL is that for OpenGL ES 2.0, I specify an additional config parameter of EGL_RENDERABLE_TYPE. Also, for Context Attributes, I specify CONTEXT_CLIENT_VERSION to be equal to 2. Other than these 2 differences, the EGL usage for both versions of the OpenGL ES is the same. If things are really out of order on my side, then why the OpenGL ES 1.1 stuff is working all right?

     

    #33441

    prabindh
    Member

    Would it be possible to move to a later version of the SDK ? 06 seems pretty old to me.

     

    Download (Needs a little registration)

     

     

    Getting started:

    #33442

    jrshah
    Member

    The latest Graphics SDK version is 00_00_09, so should I move to this particular version of the SDK with latest libraries and avoid using 00_00_06? Will it work with Linux kernel 2.6.29? 

    #33443

    jrshah
    Member

    I have just migrated to latest Graphics SDK (00_09) and the EGL_BAD_ALLOC disappeared. Great to see that! However, the problem does not end here. Now the OpenGL ES 2.0 code is executing without generating any OpenGL ES error. However, on the display side, I cannot see any thing except the blank white screen. I mean to say that whatever is rendered through OpenGL ES 2.0, nothing is appearing on the screen. It is to note that vertex and fragment shaders are compiling successfully and they are linked successfully as well. There is no OpenGL ES 2.0 error reported by glGetError(). Still, not even a little bit is appearing on screen. Any one having any thoughts about this…?

    #33444

    prabindh
    Member

    Maybe you have a wrong shader compiled ? Please look at the sgxperf2.0 code base I linked earlier for reference implementations of simple “passthrough” shaders.

    #33445

    jrshah
    Member

    Well, I do not think that I have a wrong shader compiled. In my test application, both lighting and textures are used. What I have figured so far is that the textures are working all right. However, the lighting calculations seem to have problems somewhere. As the gl_FragColor is computed using both the texture color and the lighting color, nothing appears on screen expect the white color. I am looking into the lighting portion to make it work alongside texture mapping… 

    #33446

    jrshah
    Member

    At last, I have been able to run my application. However, the rendering is very slow. The frame rate is about 3-5 fps. Regarding performance improvement on the hardware, should I just revisit my shader implementation or should I also consider the way values are passed to these shaders at runtime? Any suggestions are greatly appreciated. Thanks.

    – J R Shah

Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic.