[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On Thu, 21 Jun 2018 at 12:11, Tim Moore <timoore33 at gmail.com> wrote:

> This is not the way shared_ptr is implemented, at least in gcc. The shared
> pointer contains a pointer to the object as well as to the control block.
> You could argue that this makes a shared_ptr twice the size of an
> osg::ref_ptr, but I really can't speculate on the overall effect on memory
> usage.
>

16 bytes instead of 8 for every single pointer... plus the extra shared
pointer object... is it just a pointer + atomic?

shared_ptr<> is a "solution" to how do I share types like an int, but it's
not at a good solution for situations where intrusive reference counting is
trivial to provide as part of class design.

Intrusive reference counting is a far better solution for a scene graph,
there isn't a comparison.  Frankly I can't believe I'm even having to
explain this, shared_ptr<> is a niche solution that gets way more airtime
than is deserves.



> So... as my aim where possible is to make the VulkanSceneGraph more
>> efficient than the OpenSceneGraph I can't just put chains around my ankles
>> by adopting shared_ptr<>, instead I will acknowledge where the
>> OpenSceneGraph already does something well and following this approach,
>> albeit in a modern C++ way.
>>
>> For the thread safe observer_ptr<> you do need a separate auxiliary
>> object, just like the OSG, so in my prototyping this is already what I have
>> done.  I already have an vsg::Auxiliary object that is created when
>> required, this Auxiliary object is for more than just supporting
>> observer_ptr<> though, it also stores optional extra user data.  Doing this
>> shrinks the base vsg::Object/Node classes and improves memory utilization,
>> providing a measurable gain in construction, destruction and traversal of
>> the scene graph over what can be done with the OSG.
>>
> What's the measured gain?
>

Measurable gain as in timing stats, the approach I'm exploring for the
VulkanSceneGraph is faster for creating objects, destructing objects and
traversal.  Good for all users, especially any time we are paging data.



> Of course I trust your judgement, but I struggled mightily with weak
> pointer thread safety back in the day and am happy to be able to make it
> someone else's problem now. I am very happy that VulkanSceneGraph is coming
> on the scene!
>

I remember all the pain getting is to work robustly.  My experiments build
upon what the OSG does currently, but using std::atomic, as well as
discarding a lot of baggage that the OSG has due to it's long history, it's
far, far cleaner. Yes we'll hammering with mutti-threaded stress cases to
make sure what we end up with is solid implementation, but with the
implementation being so much cleaner I expect the process to be a lot less
painful.

Things like ref_ptr<>/observer_ptr<> are just a tiny bit of what I'm
looking at in the Exploration Phase, these are really just a footnote
compared to the wider design and implementation issues.

Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180621/fef9a40a/attachment.html>