There could be a couple issues either of which on it's own could potentially cause the problem you're describing, 
however both in combination would also be possible which would cause things to be even worst.

The first issue, is that version of the SGX driver requires textures to be allocated physically contiguous, which means 
it can fail if system memory becomes too fragment. The second, is the mechanism where the SGX driver ghost textures 
which is to say it creates temporary copies of textures on certain scenes in order to allow things to work correctly 
with the deferred rendering architecture.

That version of the SGX driver is about 4 years old, I would recommend trying to get a more recent SGX driver, which 
would support discontiguous physical memory for textures and would also have a great deal of improvement in management 
of ghosted resources to keep memory overhead to a minimum. Alternatively, if you're stuck with that drivers, there's a 
long list of common strategies for avoiding memory fragmentation and you should be aware that ghosting can occur in 
particular cases like rendering to one FBO then using the results of that FBO to render to the default framebuffer 
within a single frame.

-Joel

________________________________________
From: David Beberman [community-noreply@qnx.com]
Sent: Thursday, July 17, 2014 11:39 AM
To: momentics-community
Cc: dbeberman@aicas.com
Subject: GL_OUT_OF_MEMORY returned from OpenGL ES 1.1 when creating textures -- with low system memory

We are seeing the GL_OUT_OF_MEMORY returned on creating textures and binding 2D images with
OpenGL ES 1.1 API on QNX 6.5 and QNX 6.6.
This only occurs when available system memory is down to 25MB to 40MB.
This does not occur when available system memory is higher, say at 70MB.
The amount of textures being created is in the range of 4096.  This is done
for performance reasons when redrawing various textures.
We have used the glDeleteTexture API to reduce the number of textures.
This has not changed the behavior. We have also used the glFlush API to make sure
the deletes are occurring.

The textures are small compared to the available 25 - 40 MB of system memory.
Regular malloc() allocations succeed, so there is not a complete memory exhaustion issue.
This looks like something internal to the OpenGL ES library, or something specific
to the GPU.
The target CPU is an TI-OMAP5530.
The GPU on the TI SOC is PowerVR SGX 530.
The OpenGL driver is build 1.4, version 1.6.16.3977 from Imagination.

This does not cause crashes.  The symptom is white rectangles are drawn on the screen.
This is the correct behavior when the GL_OUT_OF_MEMORY occurs in the OpenGL ES library.
However the behavior is not usable for the application.
The screen is in the range of 640x480 or larger, but not 1280x1024.  Not sure that this is relevant though.

We have seen a lot of posts about GL_OUT_OF_MEMORY from google searches.
Current workaround is to avoid texture allocations by allocating a large texture in advance and
use the subtexture API.  In progress on that.

Any suggestions, similar experiences out there?

Thanks
Contact information:
dbeberman@aicas.com




_______________________________________________

QNX Momentics Community Support
http://community.qnx.com/sf/go/post111097
To cancel your subscription to this discussion, please e-mail momentics-community-unsubscribe@community.qnx.com