Discussion:
[Opensg-users] FBO cleanup
Michael Raab
2014-09-25 14:00:04 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div>

<div>&nbsp;</div>

<div>I&#39;m using a passive window with a FBOViewport attached to create screenshots. Works great, but while searching for a memory leak, I found out that the FBO attached to the FBOViewport gets not cleaned up.</div>

<div>The OpenSG FieldContainers for the FBO, FBOViewport and PassiveWindow get destructed but glDeleteFramebuffer or glDeleteFramebufferEXT are never called. This should be done by FrameBufferObject::handleDestroyGL but this never gets called. Actually I don&#39;t know why?! Could someone please have I look?</div>

<div>&nbsp;</div>

<div>Thanks,</div>

<div>Michael</div>

<div>&nbsp;</div></div></body></html>
Carsten Neumann
2014-09-26 05:54:59 UTC
Permalink
Hello Michael,

On 09/25/2014 04:00 PM, Michael Raab wrote:
> I'm using a passive window with a FBOViewport attached to create
> screenshots. Works great, but while searching for a memory leak, I found
> out that the FBO attached to the FBOViewport gets not cleaned up.
> The OpenSG FieldContainers for the FBO, FBOViewport and PassiveWindow
> get destructed but glDeleteFramebuffer or glDeleteFramebufferEXT are
> never called. This should be done by FrameBufferObject::handleDestroyGL
> but this never gets called. Actually I don't know why?! Could someone
> please have I look?

is the Window going away at the same time as the FBO? In that case there
is no Window::doFrameExit run after the FBO is destroyed, so there is no
period where the OpenGL context is active and the corresponding GL
object can be cleaned up - in general GL objects are only destroyed at
the end of the (following) frame.
To allow the Window to perform this cleanup without rendering a frame
you can call Window::runFrameExit.

Cheers,
Carsten
Michael Raab
2014-09-26 08:38:06 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hello Carsten,</div>

<div>&nbsp;</div>

<div>removal of FBO seems to work now. Thanks.</div>

<div>While debugging I found out that the size of DisplayLists and VBO&#39;s increase also. Seems the initial set gets recreated with each Screenshot, and of course never destructed. I guess the PassiveWindow causes this as OpenSG links GLObjects to a specific window, correct? I think that&#39;s not the behavior I need as all the (gl)objects I need for the screenshot are already created. What I need to do is to redirect the rendering content from my main window to a specific FBO as the screenshot may have a different size as the main window. Is there a better/more efficient way to do this?</div>

<div>&nbsp;</div>

<div>Thanks,</div>

<div>Michael</div>

<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Freitag, 26. September 2014 um 07:54 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Carsten Neumann&quot; &lt;***@gmail.com&gt;<br/>
<b>An:</b>&nbsp;opensg-***@lists.sourceforge.net<br/>
<b>Betreff:</b>&nbsp;Re: [Opensg-users] FBO cleanup</div>

<div name="quoted-content">Hello Michael,<br/>
<br/>
On 09/25/2014 04:00 PM, Michael Raab wrote:<br/>
&gt; I&#39;m using a passive window with a FBOViewport attached to create<br/>
&gt; screenshots. Works great, but while searching for a memory leak, I found<br/>
&gt; out that the FBO attached to the FBOViewport gets not cleaned up.<br/>
&gt; The OpenSG FieldContainers for the FBO, FBOViewport and PassiveWindow<br/>
&gt; get destructed but glDeleteFramebuffer or glDeleteFramebufferEXT are<br/>
&gt; never called. This should be done by FrameBufferObject::handleDestroyGL<br/>
&gt; but this never gets called. Actually I don&#39;t know why?! Could someone<br/>
&gt; please have I look?<br/>
<br/>
is the Window going away at the same time as the FBO? In that case there<br/>
is no Window::doFrameExit run after the FBO is destroyed, so there is no<br/>
period where the OpenGL context is active and the corresponding GL<br/>
object can be cleaned up - in general GL objects are only destroyed at<br/>
the end of the (following) frame.<br/>
To allow the Window to perform this cleanup without rendering a frame<br/>
you can call Window::runFrameExit.<br/>
<br/>
Cheers,<br/>
Carsten<br/>
<br/>
------------------------------------------------------------------------------<br/>
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer<br/>
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports<br/>
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper<br/>
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer<br/>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=154622311&amp;iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=154622311&amp;iu=/4140/ostg.clktrk</a><br/>
_______________________________________________<br/>
Opensg-users mailing list<br/>
Opensg-***@lists.sourceforge.net<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div></div></body></html>
Carsten Neumann
2014-09-29 12:45:33 UTC
Permalink
Hello Michael,

On 2014-09-26 10:38, Michael Raab wrote:
> Hello Carsten,
> removal of FBO seems to work now. Thanks.
> While debugging I found out that the size of DisplayLists and VBO's
> increase also. Seems the initial set gets recreated with each
> Screenshot, and of course never destructed. I guess the PassiveWindow
> causes this as OpenSG links GLObjects to a specific window, correct?

yes, for most (all?) purposes you can think of a Window == OpenGL context.

> I think that's not the behavior I need as all the (gl)objects I need for
> the screenshot are already created. What I need to do is to redirect the
> rendering content from my main window to a specific FBO as the
> screenshot may have a different size as the main window. Is there a
> better/more efficient way to do this?

Right, that is the purpose of Stage (and derived) NodeCores, they can
redirect the rendering of the tree below them into an FBO.
Examples/Simple/fbotexture.cpp shows how this can be done with the
SimpleStage.
For making screenshots you could keep the Stage above the 'normal' root
of your scene and normally start rendering at that root. If you want to
create a screenshot start rendering at the Stage above it, i.e.
temporarily change the root used by the viewport.

Cheers,
Carsten
Michael Raab
2014-10-07 11:14:00 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hello Carsten,</div>

<div>&nbsp;</div>

<div>this way it works much better. But there is one thing remaining. We have some shaders that a time dependent. So I have to update a uniform variable before each frame.</div>

<div>During video capture I have to update that var, render to FBO (for the video frame) and afterwards render to backbuffer (the usual frame). The variable update seems to affect only the FBO rendering.</div>

<div>In the usual scene rendering the timed shader behavior stops until the video capturing gets stopped. I checked with gDebugger and in case of capturing the video the GLContext receives a copy of the initial shading program and the variable update seems to affect only this.</div>

<div>&nbsp;</div>

<div>Thanks,</div>

<div>Michael</div>

<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Montag, 29. September 2014 um 14:45 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Carsten Neumann&quot; &lt;***@gmail.com&gt;<br/>
<b>An:</b>&nbsp;opensg-***@lists.sourceforge.net<br/>
<b>Cc:</b>&nbsp;***@googlemail.com<br/>
<b>Betreff:</b>&nbsp;Re: [Opensg-users] FBO cleanup</div>

<div name="quoted-content">Hello Michael,<br/>
<br/>
On 2014-09-26 10:38, Michael Raab wrote:<br/>
&gt; Hello Carsten,<br/>
&gt; removal of FBO seems to work now. Thanks.<br/>
&gt; While debugging I found out that the size of DisplayLists and VBO&#39;s<br/>
&gt; increase also. Seems the initial set gets recreated with each<br/>
&gt; Screenshot, and of course never destructed. I guess the PassiveWindow<br/>
&gt; causes this as OpenSG links GLObjects to a specific window, correct?<br/>
<br/>
yes, for most (all?) purposes you can think of a Window == OpenGL context.<br/>
<br/>
&gt; I think that&#39;s not the behavior I need as all the (gl)objects I need for<br/>
&gt; the screenshot are already created. What I need to do is to redirect the<br/>
&gt; rendering content from my main window to a specific FBO as the<br/>
&gt; screenshot may have a different size as the main window. Is there a<br/>
&gt; better/more efficient way to do this?<br/>
<br/>
Right, that is the purpose of Stage (and derived) NodeCores, they can<br/>
redirect the rendering of the tree below them into an FBO.<br/>
Examples/Simple/fbotexture.cpp shows how this can be done with the<br/>
SimpleStage.<br/>
For making screenshots you could keep the Stage above the &#39;normal&#39; root<br/>
of your scene and normally start rendering at that root. If you want to<br/>
create a screenshot start rendering at the Stage above it, i.e.<br/>
temporarily change the root used by the viewport.<br/>
<br/>
Cheers,<br/>
Carsten<br/>
<br/>
------------------------------------------------------------------------------<br/>
Slashdot TV. Videos for Nerds. Stuff that Matters.<br/>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=160591471&amp;iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=160591471&amp;iu=/4140/ostg.clktrk</a><br/>
_______________________________________________<br/>
Opensg-users mailing list<br/>
Opensg-***@lists.sourceforge.net<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div></div></body></html>
Carsten Neumann
2014-10-07 14:39:36 UTC
Permalink
Hello Michael,

On 2014-10-07 13:14, Michael Raab wrote:
> this way it works much better. But there is one thing remaining. We have
> some shaders that a time dependent. So I have to update a uniform
> variable before each frame.

ok.

> During video capture I have to update that var, render to FBO (for the
> video frame) and afterwards render to backbuffer (the usual frame). The
> variable update seems to affect only the FBO rendering.

just to make sure I understand it correctly: the variable has (or should
have) the same value when rendering to the FBO and the regular back buffer?

> In the usual scene rendering the timed shader behavior stops until the
> video capturing gets stopped. I checked with gDebugger and in case of
> capturing the video the GLContext receives a copy of the initial shading
> program and the variable update seems to affect only this.

Hmm, here I'm not sure I can follow: my understanding was that your
setup now only has one GL context (Window) that is used for both
rendering to the FBO as well as the regular back buffer and so there
should only be one instance of the shader program? Do you think you can
track down where that copy comes from, because I have a feeling that
there should not be a copy in the first place - that way there would
also not be any confusion which program's uniform value gets updated.

Cheers,
Carsten
Michael Raab
2014-10-07 15:10:29 UTC
Permalink
Hello Carsten,

Am 07.10.2014 16:39 schrieb Carsten Neumann <***@gmail.com>:
>
> Hello Michael,
>
> On 2014-10-07 13:14, Michael Raab wrote:
> > this way it works much better. But there is one thing remaining. We have
> > some shaders that a time dependent. So I have to update a uniform
> > variable before each frame.
>
> ok.
>
> > During video capture I have to update that var, render to FBO (for the
> > video frame) and afterwards render to backbuffer (the usual frame). The
> > variable update seems to affect only the FBO rendering.
>
> just to make sure I understand it correctly: the variable has (or should
> have) the same value when rendering to the FBO and the regular back buffer?
>

Correct.

> > In the usual scene rendering the timed shader behavior stops until the
> > video capturing gets stopped. I checked with gDebugger and in case of
> > capturing the video the GLContext receives a copy of the initial shading
> > program and the variable update seems to affect only this.
>
> Hmm, here I'm not sure I can follow: my understanding was that your
> setup now only has one GL context (Window) that is used for both
> rendering to the FBO as well as the regular back buffer and so there
> should only be one instance of the shader program? Do you think you can
> track down where that copy comes from, because I have a feeling that
> there should not be a copy in the first place - that way there would
> also not be any confusion which program's uniform value gets updated.
>

Yes there is one context and the shader program instance should be there once. Actually I have no clue where and why it is constructed. Do have an idea where to start looking for it?

Michael

> Cheers,
> Carsten
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensg-users mailing list
> Opensg-***@lists.sourceforge.net
> https://lists.so
Carsten Neumann
2014-10-08 14:59:53 UTC
Permalink
Hello Michael,

On 10/07/2014 05:10 PM, Michael Raab wrote:
> Am 07.10.2014 16:39 schrieb Carsten Neumann <***@gmail.com>:
>>> In the usual scene rendering the timed shader behavior stops until the
>>> video capturing gets stopped. I checked with gDebugger and in case of
>>> capturing the video the GLContext receives a copy of the initial shading
>>> program and the variable update seems to affect only this.
>>
>> Hmm, here I'm not sure I can follow: my understanding was that your
>> setup now only has one GL context (Window) that is used for both
>> rendering to the FBO as well as the regular back buffer and so there
>> should only be one instance of the shader program? Do you think you can
>> track down where that copy comes from, because I have a feeling that
>> there should not be a copy in the first place - that way there would
>> also not be any confusion which program's uniform value gets updated.
>>
>
> Yes there is one context and the shader program instance should be there once. Actually I have no clue where and why it is constructed. Do have an idea where to start looking for it?

hmm, not sure if it's helpful, but there is essentially just one place
that calls glCreateProgram: OSGShaderExecutableChunk.cpp:260, so that
may be a starting point?

Cheers,
Carsten
Michael Raab
2014-10-10 08:20:07 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hello Carsten,</div>

<div>&nbsp;</div>

<div>the problem is solved but actually I&#39;m not sure why. glCreateProgram was called twice by OSGSimpleSHLChunk::handleGL. Seems that the uiProgram value that handleGL() retrieves from pWin was no ok.</div>

<div>I solved it by calling frameInit() and frameExit() around renderAllViewports(). In that case I did not call render() as I do not what the window to swap() as I have the FBO as target.</div>

<div>Can you tell me what frameInit() is doing?</div>

<div>&nbsp;</div>

<div>Thanks,</div>

<div>Michael</div>

<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Mittwoch, 08. Oktober 2014 um 16:59 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Carsten Neumann&quot; &lt;***@gmail.com&gt;<br/>
<b>An:</b>&nbsp;opensg-***@lists.sourceforge.net<br/>
<b>Betreff:</b>&nbsp;Re: [Opensg-users] FBO cleanup</div>

<div name="quoted-content">Hello Michael,<br/>
<br/>
On 10/07/2014 05:10 PM, Michael Raab wrote:<br/>
&gt; Am 07.10.2014 16:39 schrieb Carsten Neumann &lt;***@gmail.com&gt;:<br/>
&gt;&gt;&gt; In the usual scene rendering the timed shader behavior stops until the<br/>
&gt;&gt;&gt; video capturing gets stopped. I checked with gDebugger and in case of<br/>
&gt;&gt;&gt; capturing the video the GLContext receives a copy of the initial shading<br/>
&gt;&gt;&gt; program and the variable update seems to affect only this.<br/>
&gt;&gt;<br/>
&gt;&gt; Hmm, here I&#39;m not sure I can follow: my understanding was that your<br/>
&gt;&gt; setup now only has one GL context (Window) that is used for both<br/>
&gt;&gt; rendering to the FBO as well as the regular back buffer and so there<br/>
&gt;&gt; should only be one instance of the shader program? Do you think you can<br/>
&gt;&gt; track down where that copy comes from, because I have a feeling that<br/>
&gt;&gt; there should not be a copy in the first place - that way there would<br/>
&gt;&gt; also not be any confusion which program&#39;s uniform value gets updated.<br/>
&gt;&gt;<br/>
&gt;<br/>
&gt; Yes there is one context and the shader program instance should be there once. Actually I have no clue where and why it is constructed. Do have an idea where to start looking for it?<br/>
<br/>
hmm, not sure if it&#39;s helpful, but there is essentially just one place<br/>
that calls glCreateProgram: OSGShaderExecutableChunk.cpp:260, so that<br/>
may be a starting point?<br/>
<br/>
Cheers,<br/>
Carsten<br/>
<br/>
------------------------------------------------------------------------------<br/>
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer<br/>
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports<br/>
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper<br/>
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer<br/>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=154622311&amp;iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=154622311&amp;iu=/4140/ostg.clktrk</a><br/>
_______________________________________________<br/>
Opensg-users mailing list<br/>
Opensg-***@lists.sourceforge.net<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div></div></body></html>
Carsten Neumann
2014-10-13 06:22:51 UTC
Permalink
Hello Michael,

On 10/10/2014 10:20 AM, Michael Raab wrote:
> the problem is solved but actually I'm not sure why. glCreateProgram was
> called twice by OSGSimpleSHLChunk::handleGL. Seems that the uiProgram
> value that handleGL() retrieves from pWin was no ok.
> I solved it by calling frameInit() and frameExit() around
> renderAllViewports(). In that case I did not call render() as I do not
> what the window to swap() as I have the FBO as target.
> Can you tell me what frameInit() is doing?

had to look that up first: it initializes extensions and fetches the
relevant function pointers from the GL context to cache them. Without it
extensions won't work properly on the context.

Cheers,
Carsten
Loading...