OUT_OF_MEMORY in glDrawElements

[the_milord]

Hi everyone,
I have a small application which renders a moderately sized mesh (4440 indices), using 6 attributes per vertex and active 4 texture units. The attributes are :
1x vec3 for position
4x vec2 for texture coordinates
1x vec4 for texture weights
I am doing blending of the 4 textures basing on the weights in vec4 attribute. The textures are 1280x800 pixels, greyscale GL_ALPHA format

On calling the glDrawElements in the first frame I get a OUT_OF_MEMORY error, which according to OGLES 2.0 spec should even be generated by this call. I am 100% sure that the error comes from this call, I am clearing the glError flag before.
I have tested the application on two other ARM plaforms with Open GL ES 2.0 (TI OMAP 3730 & I.MX.6) and in the PowerVR emulator where it runs fine, so I guess it is RASPI specific.
I have thought that it might be because I am using no VBO, but tested it on RASPI with VBO and the problem persists.
Is there some limitation in VideoCore which prevents me from rendering mesh in above configuration?
Have somebody encountered such error before?
I am using 128MB/128MB memory split, running on Arch Linux and Raspbian.
Thanks in advance for any hints

[jackokring]

I haven't, and the numbers "look" good at under 128MB. I got many errors on application close if I did not dispose my texture. So if the 16MB (about as just alpha) of textures are expanded as full colour on the hardware, would the numbers add up? 4*16*4000 bytes about for the mesh, so it's tiny insignificant compared to the textures. Then there is the frame buffer (16MB about), and the double buffer perhaps for another 16MB.

[dom]

Code: Select all

vcdbg reloc

Can be used to see the memory allocated on GPU.

[blu]

I faced the same issue some time ago - glDraw* ending in GL_OUT_OF_MEMORY, but the issue in my case was the shader compiler - the vertex shader was too complex. I suggest you dumb down your shaders for the sake of the experiment.

[the_milord]

Thanks for all the input. Owing to blu's tip I took a look into the shaders, they are in my case quite complex indeed (doing 4 frames planar YUV conversion to RGB on the fly ), but the complexity itself is not the problem i guess. It seems like the driver doesn't handle/optimize static branches very well, here is my example:

uniform doYUVconversion
[...]
if(doYUVconversion)
{
reallyComplexStuff()
}
else
{
do only basic RGB
}

The above won't run, and ends in OUT_OF_MEMORY.
if I only leave the reallyComplexStuff() however, then it runs perfectly.
So the videoCore actually needs to run the same code but it fails when there is a unused branch.
For comparison : AFAIK the driver for OMAP 3730 would track the changes (glUniform calls) to the "doYUVconversion" uniform and use only the needed resources. I thought that it is a standard procedure in GLSL implementation, but obviously i was wrong

Thank you for your help.