Re: [osg-users] Potential fix for osgDB MSVC linkage issues (FORCE:MULTIPLE needed)

[James Turner]

> On 9 Aug 2016, at 10:21, Robert Osfield  wrote:
> 
> I'm happy to merge the changes, could you raise a pull request based
> on these changes?

https://github.com/openscenegraph/OpenSceneGraph/pull/115

Kind regards,
James

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Robert Osfield]

Hi Jannik,

On 15 August 2016 at 15:03, Jannik Heller  wrote:
> Given that there is no documentation suggesting that removing RTT camera's is 
> unsafe - I just assumed it was a bug :)

You can't document a issue if you haven't conceived of the specific
usage case that it's associated with :-)

What you are doing is very narrow type of usage.

> As a workaround I believe that removing the Camera's children before removing 
> the camera should fix the crash. That means releaseGLObjects() won't be 
> called on the Camera's subgraph on destruction but to be honest that feature 
> seems broken to me anyway:
>
> What the intent probably was:
> - release any GL resources that are only used by this Camera
>
> What the code actually does:
> - release any GL resources of a Node only used by this Camera *and* all its 
> child-nodes (which may be shared resources still in use by other Cameras).
>
> What are your thoughts on removing the releaseGLObjects() stuff from 
> GraphicsContext::removeCamera - it is not working as intended, and removing 
> it would fix the race condition as a side effect :)

Adding and removing nodes from the scene graph while it's being
co-concurrently rendered is a tough ask. There are very specific
mechanisms in place to help make it possible - i.e. PagedLOD.

The releaseGLObjects() and removeCamera() are there to make sure
resources are correctly cleaned up.  If you really try you can break
it, like hiding resources from that active parts of the viewer/scene
graph that are their to clean up things.

The key issue you are trying to push the OSG in ways that it's not
designed to handle.  If you want to dynamically add/remove Camera's
nodes then you'll need to you'll need to halt the multi-threading of
draw while you do it.

You can say the OSG should support your particular usage case but
making this possible could well be intrusive to the rest of the OSG.
The OSG has to balance the way things are designed and implemented to
make keep the feature/complexity and performance balance justified.

For your particular usage model I think the approach is pretty easy to
implement or to workaround within the client application - switch off
threading when you do unsafe tasks, or just toggle the Camera on/off.

However, ff you can spot an easy way to fix things for your usage case
without interfering with the performance and simplicity of the current
design then propose it.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Jannik Heller]

Hi,


> 
> Your crash suggests otherwise :-) 
> 


Given that there is no documentation suggesting that removing RTT camera's is 
unsafe - I just assumed it was a bug :)

As a workaround I believe that removing the Camera's children before removing 
the camera should fix the crash. That means releaseGLObjects() won't be called 
on the Camera's subgraph on destruction but to be honest that feature seems 
broken to me anyway:

What the intent probably was:
- release any GL resources that are only used by this Camera

What the code actually does:
- release any GL resources of a Node only used by this Camera *and* all its 
child-nodes (which may be shared resources still in use by other Cameras).

What are your thoughts on removing the releaseGLObjects() stuff from 
GraphicsContext::removeCamera - it is not working as intended, and removing it 
would fix the race condition as a side effect :)

Cheers,
Jannik

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68377#68377





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Robert Osfield]

Hi Jannik,

On 15 August 2016 at 13:21, Jannik Heller  wrote:
> As far as I'm aware, in-scene graph cameras are not supposed to be subject to 
> threading issues and *should* be safely removable without stopping the viewer 
> threading.

Your crash suggests otherwise :-)

I think you've hit upon a usage model that the RenderStage/core OSG
design wasn't envisaged in their design and implementation.
Specifically, the DrawThreadPerContext theading model is princpally
built around the idea that only the Drawable and StateSet leaves of
the scene graph make it into the rendering backend
(RenderStage/RenderBin) data structures and any modifications to these
are controlled using osg::Object::DataVariance(), it's assumed that
the scene graph nodes don't affect what's happening in the rendering
backend once it's built by the CullVisitor.  Here, Camera nodes are
actually part of the Rendering back-end thus breaking the assumption
of the design, this is fine as long a you don't go modifying the
Camera's or their contents which the draw traversal is running.  I
believe it would still work fine had you not shared the Camera's
subgraph so that it outlived the Camera that once owned it.

I've just done a review of the affected code in
src/osgViewer/Renderer.cpp and src/osgUtil/RenderStage.cpp and can't
spot a way of prevent the problem when you configure the scene graph
and doing the deletion the way you are doing it.  It wasn't written
for this particular usage in mind, it may be possible to retrofit
support for this but I have plenty of other tasks to get on with which
aren't quite so obscure and specific to a narrow usage model.

For yourself my original recommendations are still valid - either
stopThreading, remove the camera, then start threading, or just toggle
on/off Camera via NodeMask rather than adding/removing on the fly.
The later is my preference when doing this types of tasks as creation
and deletion of C++ and OpenGL objects is expensive so not something
you would generally want to do in a real-time graphics application.
If you don't have a real-tme graphics application and don't care about
frame-rate then just run SingleThreaded or ThreadPerCamera.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Jannik Heller]

Hi Robert,

I know about the restriction with viewer-level cameras (add/removeSlave).  I'm 
not using those. I'm using in-scenegraph cameras for render to texture effects.

subgraph->addChild(rttCamera);

As far as I'm aware, in-scene graph cameras are not supposed to be subject to 
threading issues and *should* be safely removable without stopping the viewer 
threading. 

Thank you!

Cheers,
Jannik

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68375#68375





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight

[Robert Osfield]

Hi Julien et. al,

On 14 August 2016 at 23:21, Julien Valentin  wrote:
> Recently Robert opens a new branch for the integaration of VAO in osg.

To check it out have a look at the VAO branch:

  git checkout vertex_array_object

Then rebuild the OSG,  To enable use of VAO you can set the a new env
var OSG_VERTEX_BUFFER_HINT to VAO.  i.e.

  export OSG_VERTEX_BUFFER_HINT=VAO
  osgviewer cow.osgt


The approach I have taken is to have one Vertex Array Object per
osg:Drawable and not share them.  Design and speed wise I feel this is
the best balance as the OpenGL VAO is intended to make setting vertex
arrays lightweight, since the OSG set's arrays within osg::Geometry
then the natural affinity of VAO is to sit alongside the existing
vertex array calls.  You don't share vertex array set up between
osg::Geometry so there is no need to force sharing of VAO's, they can
happily just sit there a be used when enabled but otherwise ignored.

What could be an advantage to share is the Vertex Buffer Objects's
between osg::Geometry.  This is already possible (on OSG-3.0 onwards)
if you assign the osg::VertexBufferObject and osg::ElementBufferObject
to the osg:Array and osg::PrimitiveSet before hand rather than rely
upon the osg::Geometry to assign it's own.  The new VAO support in the
vertex_array_object branch still supports this so you can share VBO's
between osg::Geometry, while each osg::Geometry has it's own VAO.

The design I have gone for takes into account the need for the feature
to work with existing codes as much as possible without adaptation.
This hasn't been trivial to do, I don't know yet how close I am to
this goal but I've got the majority of the OSG working well.  Wider
testing out in the community will reveal how well it's working.

Performance wise, In city model I'm used for testing the I'm seeing up
to a 30% boost in framerate when comparing VAO+VBO's vs VBO's.  Alas
DisplayLists are still king for this model, looks like NVidia drivers
do a great job in optimizing display lists even today.  The city model
I'm testing has lots of separate osg::Geoemetry, with the model
originally loaded from OpenFlight.

>
> I've thrown a fast look at it,but have not tested yet  -not enough HD space:/ 
> so I can't give a full feedback
> I can only compare with my own impl with this reduced perspective, I don't 
> understand all so don't be regardant if i misunderstood the code.
>
> In my implementation:
> -I assumed the only way to fully take care of the performance bonus of VAO in 
> osg was to share BO among geometries.
>  I use a singleton to manage bo sets involved in vaos, it concatenates 
> bufferdata in these bo and so bos and vao are shared among geometries
> -However concatenate arrays in a bo brings a problem of offset in bo so i 
> have to quit glDrawElementsXXX to glDrawElemntsXXXbasevertex
> So each arrays of a geometry must have the same start index in the 
> bufferobjects and geometries should share the same bo set as often as possible
>
> I did a test in debug build (on a GTX640) with a triangle indexed city and 
> the default useVBO
> it originally frames at 40FPS
> +adding bo sharing among geometries : 55FPS
> +adding useVAO 70FPS (The Draw charge drops from 12 to 6 even if i unbind vao 
> after each geom draw)
>
> https://github dot com/mp3butcher/OpenSceneGraph
>
> In the current branch:
> -I like the idea of deporting vao in state..It seams a good place for them 
> for state sorting.
> -But I haven't spot the way intended to share VAO among Geometries:
> *bo affectation to geoms is not managed (so do we have to assume user is in 
> charge of sharing bo correctly among geoms?)
> *it seams primset doesn't take the way of basevertex draw calls so I'm asking 
> myself how could we manage basevertex when geoms arrays share same bos
>
> I opened this thread, in order others can share their point view on the 
> subject. What do you think of the current branch? How do you see the vao 
> integration in osg? Which approach should be the flexier

When going from the approach I took with the vertex_array_object
branch I reviewed your and other previous VAO approaches but felt they
wouldn't quite meet the requirements.  I feel sharing VAO between
osg::Geometry is not a good design/performance solution, lots of pain
and I'm doubtful of a gain that can justify the extra complexity.
VAO's are lightweight objects in OpenGL, having lots of them is cheap
and makes the cost of vertex array dispatch much cheaper.

For testing you really have to compare performance in a release build
as a debug build adds a huge overhead to cull and draw dispatch.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight

[wang dexing]

Hi,

I'm glad that osg's VAO edition is in hand.
I'm intersted in opengl and osg,I once tried to add 'vao' and 'instance draw' 
functions to osg because I had many same models and texts to draw and I didn't 
want to give up osg's 'cull' fuction.
It took me much time thinking about where I  should use 'vao'. In order to 
support 'instance draw',I used 'vao' in 'RenderLeaf', I calculated 'instance 
data' from 'Transform' node and other 'instance node',then put 'instance 
arrays' in 'currentstategraph'.I bind vbos in drawables and vbos of 'instance 
arrarys' to the 'vao' when renderring(first draw).what do you think of my way?
BTW,how can I join you?

Thank you!

Cheers,
wang

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68372#68372





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Robert Osfield]

Hi Jannik,

A quick reply as I don't have time right now to look into the details
of this particular crash.

As a general note, the design of osgViewer assumes that viewer level
Camera's won't be added/removed while viewer threads are running.
It's easy to just call do something like:


viewer->stopThreading();
// reconfigure viewer/camera's
viewer->startThreading();

The other approach is not not add or remove Camera's on the fly,
instead just assign them at the start of the viewer and then
enable/disable them via :

  Camera->setNodeMask(on?0x:0x0);

These two approaches might resolve the issue you have.

Robert.


On 14 August 2016 at 19:02, Jannik Heller  wrote:
> Hi,
>
> I just noticed a semi-random crash on exit in my application that seems to 
> point to a design issue in OSG.
>
> In theory a crash can happen when you remove a previously used camera from 
> the scene graph, then modify something in the subgraph of that camera (e.g. 
> remove a node's child).
>
> The race condition comes from the clearReferencesToDependentCameras() call in 
> the graphics thread. If the graphics thread held the last reference to that 
> camera, then the camera will be deleted *from the graphics thread*. The 
> camera destructor indirectly includes a call to releaseGLObjects() on the 
> camera's sub graph. The releaseGLObjects() will crash if the sub graph is 
> currently being modified by the main thread.
>
> Due to the race condition involved the crash is highly random so it's hard to 
> make a reproducible example.
>
> I suspect we haven't noticed this crash in the past because 
> clearReferencesToDependentCameras() used to be broken (see commit 
> b5a3a580762ffbeb615d73ddff732f5e8fe487b7 ).
>
> Here's a stack trace:
>
>
> Code:
>
> Thread 2 (Thread 0x7f322525c700 (LWP 12096)):
> #0  0x7f3232957ed9 in __libc_waitpid (pid=12105, stat_loc=0x7f322525b58c, 
> options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
> resultvar = 12105
> oldtype = 0
> #1  0x009a758e in crash_catcher (signum=11, siginfo=, 
> context=) at 
> /home/scrawl/Dev/openmw/apps/openmw/crashcatcher.cpp:274
> status = 0
> dbg_pid = 12105
> fd = {24, 25}
> #2  
> No locals.
> #3  0x in ?? ()
> No symbol table info available.
> #4  0x7f3236a03dd3 in osg::Group::releaseGLObjects(osg::State*) const () 
> from /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #5  0x7f3236a03dd3 in osg::Group::releaseGLObjects(osg::State*) const () 
> from /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #6  0x7f3236a03dd3 in osg::Group::releaseGLObjects(osg::State*) const () 
> from /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #7  0x7f32369fd365 in osg::GraphicsContext::removeCamera(osg::Camera*) () 
> from /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #8  0x7f323699d0ef in osg::Camera::~Camera() () from 
> /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #9  0x7f323699d629 in osg::Camera::~Camera() () from 
> /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #10 0x7f323615ca01 in 
> osgUtil::RenderStage::clearReferencesToDependentCameras() () from 
> /home/scrawl/Dev/osg/build/install/lib64/libosgUtil.so.145
> No symbol table info available.
> #11 0x7f3236168fa5 in 
> osgUtil::SceneView::clearReferencesToDependentCameras() () from 
> /home/scrawl/Dev/osg/build/install/lib64/libosgUtil.so.145
> No symbol table info available.
> #12 0x7f3235a357d9 in osgViewer::Renderer::draw() () from 
> /home/scrawl/Dev/osg/build/install/lib64/libosgViewer.so.145
> No symbol table info available.
> #13 0x7f32369fed19 in osg::GraphicsContext::runOperations() () from 
> /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #14 0x7f3236a83b7a in osg::OperationThread::run() () from 
> /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #15 0x7f3236a01418 in osg::GraphicsThread::run() () from 
> /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
> No symbol table info available.
> #16 0x7f323666f8e5 in 
> OpenThreads::ThreadPrivateActions::StartThread(void*) () from 
> /home/scrawl/Dev/osg/build/install/lib64/libOpenThreads.so.20
> No symbol table info available.
>
>
>
>
> If I had to suggest a fix I'd suggest that the 
> clear/collateReferencesToDependentCameras mechanism needs to be re-designed 
> in a way that it's impossible for the graphics thread to delete the camera.
>
> Thank you!
>
> Cheers,
> Jannik
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68367#68367
>
>
>
>
>
> ___
> osg-users mailing