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
For the right usage, you can look for examples in the Graphics SDK itself, or in the sgxperf samples online at,
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
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.
What version of the OMAP3530 EVM Graphics SDK are you using ? and what does eglinfo output ?
The eglInfo produces the following output:
egl error ‘EGL_NOT_INITIALIZED’ (0x3001) Unable to initialise egl
The SDK version is 3_00_00_06.
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?
Would it be possible to move to a later version of the SDK ? 06 seems pretty old to me.
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?
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…?
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.
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…
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
A good place to start learning how to optimise your application under OpenGL ES 2.0 is to examine the document: “POWERVR SGX.OpenGL ES 2.0 Application Development” Recommendations" which should be available through the POWERVR SDKs. Pay attention particularly to the “Golden Rules” detailed there.
For specific recommendations it’s difficult to suggest anything without knowing more about your application - what are you rendering?
What frame rate should I expect from a simple pass-through shader. What I mean from a pass-through shader is a shader that just assigns gl_Position in vertex shader and assigns a constant color to gl_FragColor. I am asking this just to know about the upper bound for the achievable frame rate through OpenGL ES 2.0 on OMAP3530. Also, how do the frame rates compare between the two versions of OpenGL ES (Just to see how the programmable pipeline can outperform the fixed-function pipeline). Any suggestions are greatly appreciated as ever. Thanks.
- J R Shah
Hello,
There is not a generic answer: Peak performance will depend on the number of polygons, the number of pixels processed, the clock speed, the resolution, etc. Clearly 3-5 fps is a very low performance which we do not see in normal applications. Could you describe your application? How many pixels are you processing and how many cycles per shader?
Best regards
Carlos.
