[osg-users] Improving multisampled FBO
Paul Martz
short summary: I want to allow applications to optionally disable the
depth buffer bit in the call to glBlitFramebuffer, so that only color is
copied.
In order to render multisampled to a texture, (with pre-GL3.2) we need
to render into a multisampled renderbuffer then glBlitFramebuffer into
the texture. (I've attached some very simple code that exercises this
code path.) To support glBlitFramebuffer, there needs to be two FBOs:
one with multisampled renderbuffers attached (call it "FBO A"), and one
with the texture attached (call it "FBO B").
OSG creates these FBOs during RenderStage::runCameraSetUp. OSG correctly
assumes that I need both color and depth multisampled renderbuffers
attached to FBO A. This is correct and is exactly what I want. OSG
creates this for me.
However, OSG _incorrectly_ assumes that I also want a depth renderbuffer
attached to FBO B, and it creates and attaches one. In fact, this is not
always necessary and is wasteful of GPU memory when it's not needed. I'm
only interested in the color buffer, and I don't need the depth buffer.
The problem is compounded during the glBlitFramebuffer call (occurs in
RenderStage::drawInner). The code determines that since both FBO A and
FBO B have color and depth attachments, that it must blit both color and
depth. Specifically, when it calls glBlitFramebuffer, the mask parameter
is (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT). This is unnecessary and
inefficient. It causes the blit to copy extra data that is not needed.
I understand that the depth attachment to FBO B might be needed in some
cases, and it's impossible for OSG to know whether it's needed or not
needed. So, I propose that OSG continue to work this way by default, but
osg::Camera should support some type of interface that allows the
application to tell OSG that the depth attachment in FBO B is not
needed, so that OSG won't bother to create it and won't include it in
the blit.
I'm on vacation/holiday Oct 4-9, and I'll be glad to make this change
after I return from my break.
All this investigation was done with v2.8.2. I've been unable to see how
things work with current svn head due to server issues and recent code
changes that prevent me from building (as noted in another post).
Finally, I'm going to need this change in order to work around an
apparent driver bug that I'm encountering on OSX with dual GF8800 cards
driving four monitors. If the resolve blit is performed with both depth
and color, it hangs my entire desktop (yuck). Removing the unnecessary
depth bit from the blit call avoids this issue. I'm still reviewing the
OpenGL spec to understand whether this is a driver bug or a problem with
OSG's usage.
Anyhow, let me know what you think. Thanks for your review time on this
change.
--
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
Wojciech Lewandowski
Month (or two) ago we merged a patch to disable color/depth buffer
enforcement in FBO setup in RenderStage. Idea was to put responsibilty for
selected attachments on the programmer. If he/she did not add depth
attachment it would be honored by RenderStage. We almost did it, but... If
you look at our changes in 2.9.5 in trunk you will notice that there are
two defines in RenderStage.cpp: FORCE_COLOR_ATTACHMENT and
FORCE_DEPTH_ATTACHMENT. They are currently set to 1. Which means missing
attachments are still added automatically. We wanted to ultimately set them
to 0, but at that moment few of the examples (osgPrerender) were relying on
adding default depth. Robert also noticed problems in osgShadow with ATI
under Linux when color attachment was not added.
Final goal is to replace this defines with flags that could be changed at
runtime. Its pretty straightforward but we did not do this last step.
Mostly because we did not decided on interface to change them. Robert
proposed that it would be good idea to select default attachment policy
through DisplaySettings. I initially objected but in the end I agreed that
this is probably the most reasonable approach. And disussion stopped then.
Others remained silent. I guess Robert had and still has so much on his
plate he could not tackle this yet. If its real emergency maybe you will be
the one who will finish it.
Cheers,
Wojtek Lewandowski
--------------------------------------------------
From: "Paul Martz" <pma...@skew-matrix.com>
Sent: Saturday, October 03, 2009 4:53 PM
To: "OpenSceneGraph Users" <osg-...@lists.openscenegraph.org>
Subject: [osg-users] Improving multisampled FBO
> // Copyright (c) 2008 Skew Matrix Software LLC. All rights reserved.
>
> #include <osg/Node>
> #include <osg/Camera>
> #include <osg/Geode>
> #include <osg/Geometry>
> #include <osg/Texture2D>
> #include <osgDB/ReadFile>
> #include <osgViewer/Viewer>
>
> #include <string>
>
>
> const int winW( 800 ), winH( 600 );
>
>
> osg::Node*
> postRender( osgViewer::Viewer& viewer )
> {
> osg::Camera* rootCamera( viewer.getCamera() );
>
> // Create the texture; we'll use this as our color buffer.
> // Note it has no image data; not required.
> osg::Texture2D* tex = new osg::Texture2D;
> tex->setTextureWidth( winW );
> tex->setTextureHeight( winH );
> tex->setInternalFormat( GL_RGBA );
> tex->setBorderWidth( 0 );
> tex->setFilter( osg::Texture::MIN_FILTER, osg::Texture::NEAREST );
> tex->setFilter( osg::Texture::MAG_FILTER, osg::Texture::NEAREST );
>
> // Attach the texture to the camera. Tell it to use multisampling.
> // Internally, OSG allocates a multisampled renderbuffer, renders to
> it,
> // and at the end of the frame performs a BlitFramebuffer into our
> texture.
> rootCamera->attach( osg::Camera::COLOR_BUFFER0, tex, 0, 0, false, 8,
> 8 );
> rootCamera->setRenderTargetImplementation(
> osg::Camera::FRAME_BUFFER_OBJECT, osg::Camera::FRAME_BUFFER );
>
>
> // Configure postRenderCamera to draw fullscreen textured quad
> osg::ref_ptr< osg::Camera > postRenderCamera( new osg::Camera );
> postRenderCamera->setClearColor( osg::Vec4( 0., 1., 0., 1. ) ); //
> should never see this.
> postRenderCamera->setRenderTargetImplementation(
> osg::Camera::FRAME_BUFFER, osg::Camera::FRAME_BUFFER );
>
> postRenderCamera->setReferenceFrame( osg::Camera::ABSOLUTE_RF );
> postRenderCamera->setRenderOrder( osg::Camera::POST_RENDER );
> postRenderCamera->setViewMatrix( osg::Matrixd::identity() );
> postRenderCamera->setProjectionMatrix( osg::Matrixd::identity() );
>
> osg::Geode* geode( new osg::Geode );
> geode->addDrawable( osg::createTexturedQuadGeometry(
> osg::Vec3( -1,-1,0 ), osg::Vec3( 2,0,0 ), osg::Vec3( 0,2,0 ) ) );
> geode->getOrCreateStateSet()->setTextureAttributeAndModes(
> 0, tex, osg::StateAttribute::ON );
> geode->getOrCreateStateSet()->setMode( GL_LIGHTING,
> osg::StateAttribute::OFF );
>
> postRenderCamera->addChild( geode );
>
> return( postRenderCamera.release() );
> }
>
> int
> main( int argc, char** argv )
> {
> osg::setNotifyLevel( osg::INFO );
>
> osg::ref_ptr< osg::Group > root( new osg::Group );
> root->addChild( osgDB::readNodeFile( "cow.osg" ) );
> if( root->getNumChildren() == 0 )
> return( 1 );
>
> osgViewer::Viewer viewer;
> viewer.setThreadingModel( osgViewer::ViewerBase::SingleThreaded );
> viewer.setUpViewInWindow( 10, 30, winW, winH );
> viewer.setSceneData( root.get() );
> viewer.realize();
>
> root->addChild( postRender( viewer ) );
>
> // Clear to white to make AA extremely obvious.
> viewer.getCamera()->setClearColor( osg::Vec4( 1., 1., 1., 1. ) );
>
> return( viewer.run() );
> }
>
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Paul Martz
In my specific case, I'm rendering multisampled to a texture, which
requires actually rendering to multisampled renderbuffers and then doing
a resolve blit to the texture. This requires 2 FBOs. And I want one to
have depth, but not the other.
Once I get back from break, I'll take a look at current svn and see if
it satisfies this criteria. But from your post, it sounds like if I
attach a depth buffer to this Camera, then it will implicitly create a
depth attachment for the resolve FBO, which is what I'm trying to avoid.
All this is pretty easy to do in OpenGL, but the fact that OSG's Camera
interface hides FBOs from the developer makes things more complex. I'd
be in favor of an interface that exposes FBOs to the developer.
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
Wojciech Lewandowski wrote:
> Hi Paul,
>
> Month (or two) ago we merged a patch to disable color/depth buffer
> enforcement in FBO setup in RenderStage. Idea was to put responsibilty
> for selected attachments on the programmer. If he/she did not add depth
> attachment it would be honored by RenderStage. We almost did it, but...
> If you look at our changes in 2.9.5 in trunk you will notice that there
> are two defines in RenderStage.cpp: FORCE_COLOR_ATTACHMENT and
> FORCE_DEPTH_ATTACHMENT. They are currently set to 1. Which means missing
> attachments are still added automatically. We wanted to ultimately set
> them to 0, but at that moment few of the examples (osgPrerender) were
> relying on adding default depth. Robert also noticed problems in
> osgShadow with ATI under Linux when color attachment was not added.
>
> Final goal is to replace this defines with flags that could be changed
> at runtime. Its pretty straightforward but we did not do this last
> step. Mostly because we did not decided on interface to change them.
> Robert proposed that it would be good idea to select default attachment
> policy through DisplaySettings. I initially objected but in the end I
> agreed that this is probably the most reasonable approach. And disussion
> stopped then. Others remained silent. I guess Robert had and still has
> so much on his plate he could not tackle this yet. If its real
> emergency maybe you will be the one who will finish it.
>
> Cheers,
> Wojtek Lewandowski
_______________________________________________
Wojciech Lewandowski
> Once I get back from break, I'll take a look at current svn and see if it
> satisfies this criteria. But from your post, it sounds like if I attach a
> depth buffer to this Camera, then it will implicitly create a depth
> attachment for the resolve FBO, which is what I'm trying to avoid.
Yes, because we did not turn former policy off. But we made all the steps to
make it possible to turn off. Now its just a mater of replacing 1 with 0 in
FORCE_COLOR_ATTACHMENT and FORCE_DEPTH_ATTACHMENT macros. Simply change
these two #defines or only FORCE_DEPTH_ATTACHMENT to 0 and recompile OSG.
Now when you don't attach DEPTH_BUFFER it won't be implicitly created.
Isn't it what you are looking for ?
> All this is pretty easy to do in OpenGL, but the fact that OSG's Camera
> interface hides FBOs from the developer makes things more complex. I'd be
> in favor of an interface that exposes FBOs to the developer.
I agree, it would be cool if we could have more control over FBO management.
Cheers,
Wojtek
Paul Martz
> Yes, because we did not turn former policy off. But we made all the
> steps to make it possible to turn off. Now its just a mater of
> replacing 1 with 0 in FORCE_COLOR_ATTACHMENT and FORCE_DEPTH_ATTACHMENT
> macros. Simply change these two #defines or only FORCE_DEPTH_ATTACHMENT
> to 0 and recompile OSG. Now when you don't attach DEPTH_BUFFER it won't
> be implicitly created. Isn't it what you are looking for ?
That's _almost_ what I'm looking for, but not quite. I'm specifically
interested in the case where a single Camera creates two FBOs to support
multisampling, and I want a depth buffer in one FBO but not the other.
(See my original post for more detail.) Currently, I always get a depth
buffer in both FBOs which is not what I want.
With your change, if I attach depth to the Camera, then I also get a
depth buffer in both FBOs, and if I don't attach a depth buffer to the
Camera, then I don't get a depth buffer in either FBO, which is also not
what I want. So your solution, as currently coded, won't help with my
situation.
However, it's good to know that there are others besides myself who have
concerns about the efficiency of the present FBO implementation.
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
_______________________________________________
Robert Osfield
I've had my head down doing desgin work/development pretty solidly for
the last 6 weeks, all open sourced work, but enough intensity of
thought and effort that I've had to cease trying to multi-task, with
in the OSG context means not chases up all topics, and merge
submissions. I really dislike getting this behind, and have been
craving a little respite from other work to allow me to pop my head up
and contribute more widely on various topic.
Alas I have just completed one set of feature deliverables for a
client only to run straight into another major chunk of client work
that has near term time constraints, which this is good for business,
and in the long term good for the OSG capabilities, it does mean the
window of opportunity for me to step back more centrally into the OSG
mix of deep discussions + development has closed for at least another
month. In this particular thread it'll mean that I'll be happy to
defer to others to discuss and propose a good solution. I'm glad to
see Wojtek diving into this thread as he's both on the ball on the
topic of FBO's and fresh from having been contributing to this area.
Between you guys and anyone else able to contribute hopefully you'll
be able to spot a good way forward.
I would also suggest following the work I'll be doing over the next
month, as I'll be need to do be doing pretty sweeping changes to lots
of the OSG backend implementation and parts of the API. My aim will
be to minimize the impact for every day OSG users, but if you're
hacking at the lower level back elements of the OSG you'll be far more
exposed to potential changes. I'll explain a bit more about what I'll
be up to on Monday when I embark on the work in earnest.
Cheers,
Robert.
Wojciech Lewandowski
> That's _almost_ what I'm looking for, but not quite. I'm specifically
> interested in the case where a single Camera creates two FBOs to support
> multisampling, and I want a depth buffer in one FBO but not the other.
> (See my original post for more detail.) Currently, I always get a depth
> buffer in both FBOs which is not what I want.
>
> With your change, if I attach depth to the Camera, then I also get a depth
> buffer in both FBOs, and if I don't attach a depth buffer to the Camera,
> then I don't get a depth buffer in either FBO, which is also not what I
> want. So your solution, as currently coded, won't help with my situation.
Ok, thanks, now I see whats the problem. I thought you were using two
cameras. I was unaware that RenderStage allocates second multisample FBO.
Indeed, turning off FORCE_DEPTH_ATTACHMENT won't help much. For this case
it should be possible to seperately define attachments for main FBO and
mutlisample FBO.
Maybe you can overcome your problem with "creative" use of two cams and
FORCE_DEPTH_ATTACHMENT == 0:
One without multismapling but with depth buffer and shared texture as color
buffer. And second camera which would have multisample buffer, no depth
buffer, and would share main color buffer texture with first camera.
I now its not long term solution but maybe such hack would temporarily work
for you ?
Cheers,
Wojtek
Paul Martz
I've posted a proposed change to osg-submissions. With my change, there
is no longer a need for the #defines Wojtek had added to RenderStage.cpp
to stop implicit creation of attachments. This is now under application
control.
In my code, I've added a new Camera method, setUseBufferMask(), and
there are three bits you can OR into the parameters. For example, if you
wanted color and stencil but not depth, you'd call:
camera->setUseBufferMask( osg::Camera::USE_COLOR_BUFFER |
osg::Camera::USE_STENCIL_BUFFER );
If you don't use this entry point, then you get the old default
behavior, which is the same as USE_COLOR_BUFFER|USE_DEPTH_BUFFER.
If you explicitly set your own attachment with attach() and then call
setUseBufferMasks but leave the corresponding bit out, your attachment
is not removed: The bit mask controls implicit creation of attachments only.
If you are doing MSFBO, you pass in two masks to control attachments to
the multisampled FBO and the resolve FBO respectively. In my case, I was
using MSFBO to render to texture, and I only needed to resolve color,
not depth. So I can now call:
camera->setUseBufferMask(
// Buffers in FBO for multisampled rendering:
osg::Camera::USE_COLOR_BUFFER | osg::Camera::USE_STENCIL_BUFFER,
// Buffers in resolve FBO:
osg::Camera::USE_COLOR_BUFFER );
This produces a color and depth attachment to the multisampled FBO, but
only color (my texture map) in the resolve FBO. So OSG will no longer
create and blit to an unnecessary resolve depth buffer.
I know this isn't the complete overhaul / explicit FBO interface we had
both expressed a desire for, but I think it creates a minimum of
disruption for the upcoming stable release and preserves backwards
compatibility, which is important.
Please test if you can, and if there are better fixes or ways to improve
this change, please suggest or submit them. Thanks.
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
_______________________________________________
Wojciech Lewandowski
Thank You. I like your solution. I cannot test it now, will do it on monday
and let you know how it went.
Cheers,
Wojtek Lewandowski
--------------------------------------------------
From: "Paul Martz" <pma...@skew-matrix.com>
Sent: Saturday, October 24, 2009 10:22 PM
To: "OpenSceneGraph Users" <osg-...@lists.openscenegraph.org>
Subject: Re: [osg-users] Improving multisampled FBO
Paul Martz
> Hi Paul,
>
> Thank You. I like your solution. I cannot test it now, will do it on
> monday and let you know how it went.
Have a good weekend. :-)
I'm starting to think a better name for this entry point would be
setImplicitBuffers(), as that's what it really does: it lets the app
tell OSG what buffer attachments to create implicitly.
But take a look when you have time and give me your thoughts, I'm open
to suggestions.
Wojciech Lewandowski
I hope Robert also reads this ;-)
I compiled your code. Everything seems fine. I agree that
setImplicitBuffers() or even setImplicitBufferAttachments() would be more
self explanatory. I would also like to have one more (global) level of
control where I would be able to set defaults for _renderBuffersMask &
_resolveBuffersMask for all cameras. I guess Robert saw a need for this as
well, when he proposed to extend DisplaySettings for this purpose. It could
be useful for already existing code like osgShadow shadow map techniques. By
zeroing _RenderBuffersMask we could make these techniques more efficient, as
most of the shadow map cameras does not need to use COLOR_ATTACHMENTS.
Extrapolating Robert sugesstion (I am trying to guess how he would tackle
this) I would add _implicitBufferAttachmentsRenderMask &
_implicitBufferAttchmentsResolveMask flags and corresponding setters and
getters to DisplaySettings structure. I would also initilize them to
defaults you had set up for the camera in your submission: ie
USE_COLOR_BUFFER | USE_DEPTH_BUFFER. In the Camera class I would add one
more enum value USE_DISPLAY_SETTINGS_MASK and would make it a default for
the Camera. This flag would mean that Camera honors flags set in associted
DisplaySettings. So it would be possible to setup defaults for all cameras
by simply changing masks in DisplaySettings instance. And it would be easy
to override global defaults with the flags and methods you added when
creating a camera. Would this work for you ?
I will prepare and submit a code with these modifications if you accept
general direction.
Cheers,
Wojtek Lewandowski
----- Original Message -----
From: "Paul Martz" <pma...@skew-matrix.com>
To: "OpenSceneGraph Users" <osg-...@lists.openscenegraph.org>
Sent: Saturday, October 24, 2009 10:38 PM
Subject: Re: [osg-users] Improving multisampled FBO
Robert Osfield
On Mon, Oct 26, 2009 at 12:06 PM, Wojciech Lewandowski
<lewan...@ai.com.pl> wrote:
> I hope Robert also reads this ;-)
Sorry missed it completely :-)
> I will prepare and submit a code with these modifications if you accept
> general direction.
I believe you guessed correctly what type of approach I'd take w.r.t
setting global defaults in DisplaySettings. The suggestion of
ImplicitBufferAttachment also sounds like it conveys an appropriate
meaning. So you have my thumbs up for making the mods and submitting
these. I haven't had a chance to review Paul original yet, so I'm
just do a best guess from this thread and the previous ones.
Cheers,
Robert.
Paul Martz
> I will prepare and submit a code with these modifications if you accept
> general direction.
Sounds good to me, please go ahead and make these changes (including the
entry point name change). And thanks for the help with this.
-Paul
Wojciech Lewandowski
if (!depthAttached)
{
if( resolveBuffersMask & osg::Camera::USE_DEPTH_BUFFER )
{
fbo->setAttachment(osg::Camera::DEPTH_BUFFER,
osg::FrameBufferAttachment(new osg::RenderBuffer(width, height, GL_DEPTH_COMPONENT24)));
depthAttached = true;
}
if (fbo_multisample.valid() &&
( renderBuffersMask & osg::Camera::USE_DEPTH_BUFFER ) )
{
fbo_multisample->setAttachment(osg::Camera::DEPTH_BUFFER,
osg::FrameBufferAttachment(new osg::RenderBuffer(width, height, GL_DEPTH_COMPONENT24, samples, colorSamples)));
depthAttached = true;
}
}
Paul Martz
The RenderStage code was already set up as follows: If doing MSFBO (and
therefore need two FBOs, one for multisampled rendering and one for
final resolve), then configure "fbo" as the resolve FBO, and When done
configuring, swap it into "_resolveFbo" (see line 554). But, if not
using MSFBO, then "fbo" is just the render fbo.
(I did not write this code, I am just the poor sap left to maintain it. :-)
My code handles this correctly: If using MSFBO, then resolveBuffersMask
is the value set by the app for the resolve buffers. But if not using
MSFBO, then resolveBuffersMask is the value set by the app for render
buffers. In both cases, resolveBuffersMask is used to configure "fbo".
So, my code is correct, in light of how the existing code is written.
I attempted to explain this briefly in code comments at lines 349-351
and also lines 377-378, but perhaps to clarify things further, you could
paste this email from me as a code comment about line 442.
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
> <mailto:osg-...@lists.openscenegraph.org>
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> ------------------------------------------------------------------------
Wojciech Lewandowski
I have just submitted proposed changes to osg-submissions. Please, see
"[osg-submissions] DisplaySettings masks for implicit buffer attachments"
thread for details.
Paul Martz
-Paul
Wojciech Lewandowski wrote:
> Hi Paul,
>
> I have just submitted proposed changes to osg-submissions. Please, see
> "[osg-submissions] DisplaySettings masks for implicit buffer
> attachments" thread for details.
>
> Cheers,
> Wojtek Lewandowski
_______________________________________________