<div dir="ltr">Hi, Robert. Thanks for quick response.<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Perhaps a flag in </span><span style="font-size:12.8px">osg::Texture might be appropriate to declare whether this Texture is<br></span><span style="font-size:12.8px">suitable for reuse or not.</span></blockquote><div> </div><div>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 ?</div><div><br></div><div>Cheers,</div><div>Wojtek </div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-09 9:31 GMT+02:00 Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Wojtek,<br>
<br>
When I implemented the texture pool it never occurred to me that<br>
textures in the pool might be assigned to FBO's and not be suitable<br>
for reallocation. This is an oversight in it's design.<br>
<br>
>From the description it sounds like the texture pool scheme needs an<br>
ability to not place texture's assigned with FBO's into the pool, or<br>
at least mark them as unsuitable for reuse.  Perhaps a flag in<br>
osg::Texture might be appropriate to declare whether this Texture is<br>
suitable for reuse or not.<br>
<br>
Robert.<br>
<br>
<br>
<br>
On 8 October 2016 at 23:16, Wojciech Lewandowski<br>
<div><div class="h5"><<a href="mailto:w.p.lewandowski@gmail.com">w.p.lewandowski@gmail.com</a>> wrote:<br>
> Hi, Robert,<br>
><br>
> I believe we encountered an issue (bug?) related to maxTexturePoolSize<br>
> handling. Our application is osgEarth + few high res overlays. We set<br>
> OSG_TEXTURE_POOL_SIZE = 350 MB. It was recommended to us as one of env vars<br>
> to let osgEarth perform optimally. Overlays are rendered as RTT cameras (FBO<br>
> + 4K x4K texture2D attachments).  Overlay textures are not refreshed every<br>
> frame. They are refreshed when some inputs change but this does not happen<br>
> every frame.  And apparently thats the problem with maxTexturePoolSize. When<br>
> we pass the texture limit and create new overlay texture, one of currently<br>
> used overlay texture GL objects gets stolen. Suddenly new overlay uses that<br>
> old GL texture object but old overlay texture is reset, its texture object<br>
> is gone and scene looks bad.<br>
><br>
> I have isolated this issue to handling of maxTexturePoolSize limit in<br>
> TextureObjectSet::<wbr>takeOrGenerate(Texture* texture). I believe I understand<br>
> that this policy may work with Textures which have Images attached. Even if<br>
> such texture has its GL object reset it may allocate or reuse new one and<br>
> reload the data from Image when its applied again. But there is no such<br>
> chance for texture which was dynamically rendered in FBO (and in fact still<br>
> attached to that FBO). In our app there is a multitude of textures with<br>
> images associated. Their GL objects can be safely "borrowed" if  memory<br>
> limit is passed. But non of them is taken and unfortunately we are hit<br>
> exactly where it hurts the most: in our FBO overlays.<br>
><br>
> So my question is: Is this a bug or we missed some flag to prevent texture<br>
> from scraping in TextureObjectSet::<wbr>takeOrGenerate ?<br>
><br>
> Cheers,<br>
> Wojtek Lewandowski<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> osg-users mailing list<br>
> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.<wbr>openscenegraph.org</a><br>
> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.<wbr>org/listinfo.cgi/osg-users-<wbr>openscenegraph.org</a><br>
><br>
______________________________<wbr>_________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.<wbr>openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.<wbr>org/listinfo.cgi/osg-users-<wbr>openscenegraph.org</a><br>
</blockquote></div><br></div>