[Cogl] Out of graphics memory resizing or packing atlas

[Robert Bragg]

On Thu, Oct 25, 2012 at 5:15 AM, Roy Amodeo <roy.amodeo at gmail.com> wrote:
> Hi,
>
> I'm not sure if this is the appropriate list for this, but here goes.

Hey, yep you've got the right place :-)

>
> 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.

Yeah we currently just rely on _cogl_texture_2d_can_create() to detect
that there would be a problem allocating a particular size but that
only really makes sure we don't exceed hardware texture size limits
and can't detect that you're out of memory.

We should really be checking the GL errors to specifically catch
OUT_OF_MEMORY errors when allocating large GL resources such as
textures buffer objects and it's a bit surprising that we don't
already do that.

I've started cooking up a patch to rectify this though I'm not
currently sure I will have the time to sort this out fully today.
Actually Neil and I who do most of the development on Cogl are
currently working towards a release of a new project next week so I
hope you'll understand if we don't manage to fix this before then.

>
> 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.

thanks for reporting the problem and also for digging into the code
too; hopefully we can land a fix soon and back porting to 1.10
shouldn't be a problem.

kind regards,
- Robert

>
> Roy
>
>
> _______________________________________________
> Cogl mailing list
> Cogl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/cogl
>