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.osfi...@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.lewandow...@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@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users- > openscenegraph.org > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org