[osg-users] OSG_TEXTURE_POOL_SIZE issue

[Robert Osfield]

Hi Wojtek,

When I implemented the texture pool it never occurred to me that
textures in the pool might be assigned to FBO's and not be suitable
for reallocation. This is an oversight in it's design.

>From the description it sounds like the texture pool scheme needs an
ability to not place texture's assigned with FBO's into the pool, or
at least mark them as unsuitable for reuse.  Perhaps a flag in
osg::Texture might be appropriate to declare whether this Texture is
suitable for reuse or not.

Robert.



On 8 October 2016 at 23:16, Wojciech Lewandowski
<w.p.lewandowski at gmail.com> wrote:
> Hi, Robert,
>
> I believe we encountered an issue (bug?) related to maxTexturePoolSize
> handling. Our application is osgEarth + few high res overlays. We set
> OSG_TEXTURE_POOL_SIZE = 350 MB. It was recommended to us as one of env vars
> to let osgEarth perform optimally. Overlays are rendered as RTT cameras (FBO
> + 4K x4K texture2D attachments).  Overlay textures are not refreshed every
> frame. They are refreshed when some inputs change but this does not happen
> every frame.  And apparently thats the problem with maxTexturePoolSize. When
> we pass the texture limit and create new overlay texture, one of currently
> used overlay texture GL objects gets stolen. Suddenly new overlay uses that
> old GL texture object but old overlay texture is reset, its texture object
> is gone and scene looks bad.
>
> I have isolated this issue to handling of maxTexturePoolSize limit in
> TextureObjectSet::takeOrGenerate(Texture* texture). I believe I understand
> that this policy may work with Textures which have Images attached. Even if
> such texture has its GL object reset it may allocate or reuse new one and
> reload the data from Image when its applied again. But there is no such
> chance for texture which was dynamically rendered in FBO (and in fact still
> attached to that FBO). In our app there is a multitude of textures with
> images associated. Their GL objects can be safely "borrowed" if  memory
> limit is passed. But non of them is taken and unfortunately we are hit
> exactly where it hurts the most: in our FBO overlays.
>
> So my question is: Is this a bug or we missed some flag to prevent texture
> from scraping in TextureObjectSet::takeOrGenerate ?
>
> Cheers,
> Wojtek Lewandowski
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>