[osg-users] OSG_TEXTURE_POOL_SIZE issue

[Wojciech Lewandowski]

Hi, Robert. Thanks for quick response.

Perhaps a flag in osg::Texture might be appropriate to declare whether this
> Texture is
> suitable for reuse or not.


Perhaps. However, I have the feeling that this flag would be equivalent to
checking if (image != NULL) in current 3.5.5 OSG code base context. I don't
see how already assigned and active image-less texture coud survive such
Take operation without a callback (or similar mechanism) to let texture
owner refresh it before apply. Considering need for supporting multiple
contexts and fact that such refresh callback would require action in draw
stage, I see this postulate (for a refresh callback) as hard to implement
and probably not used by users in practice. So I conclude that (image !=
NULL) is probably a sufficient check for now ;-). Did I skip some use case ?

Cheers,
Wojtek


2016-10-09 9:31 GMT+02:00 Robert Osfield <robert.osfield at gmail.com>:

> 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
> >
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20161009/0a32c418/attachment-0003.htm>