[Cogl] Out of graphics memory resizing or packing atlas

Roy Amodeo roy.amodeo at gmail.com
Wed Oct 24 21:15:40 PDT 2012


Hi,

I'm not sure if this is the appropriate list for this, but here goes.

I am working on a Clutter-based application on Windows 7  We've tested with
Clutter 1.8.4 / COGL 1.8.0, and with Clutter 1.10.8 / COGL 1.10.2.  We are
currently running into a problem when allocating a new COGL texture that
causes a resizing or reorganization of the atlas. Even though the texture
creation appears to succeed, all of the images are gone. The screen is
black except for the text. The only indication of a failure is a warning
that a framebuffer could not be created.

This normally happens when the atlas is being resized to 4096 x 8192, but
we've seen it with atlases from 2048 x 4096 and sometimes not until
resizing to 8192 x 8192. It happens a lot sooner when GPU-heavy
applications like Windows Media Player are running at the same time. (We
have some machines with Intel HD graphics drivers and some machines with
NVIDIA.)

I've traced it down to an out of memory error from OpenGL in
cogl_texture_2d_new_with_size()  when we create the destination texture for
the new atlas. The out of memory error is not detected, and the destination
texture appears to be created. Later when try_creating_fbo() tries to
create the framebuffer attaching the texture results in an
INCOMPLETE_ATTACHMENT error, and the blit mode falls back to the
"copy-tex-sub-image", with the unsatisfactory results described above.

We can work around this by modifying the COGL code to check for out of
memory errors when resizing the atlas. This seems to give us much better
behaviour, but it's not a complete solution. (I'm not experienced enough
with the code-base to know where to place the checking so that it is
thorough, and has minimal impact on performance.) And we can delay the
occurrence of this error by doing a better job of discarding our textures
when we do not need them. (Unfortunately, the application was originally
written to manage the textures itself, instead of leaving it to clutter.)

We would like a better way of detecting when we run out of graphics memory,
so that we can provide a meaningful error message to the user, and do a
graceful recovery.

Has anyone else run into issues with COGL running out of graphics memory
and come up with an effective way to detect and deal with it?

Thanks in advance for any information or direction.

Roy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/cogl/attachments/20121025/8bc07e6c/attachment.html>


More information about the Cogl mailing list