[osg-users] Thoughts on Vulkan

[sduclos]

wow, serious fun!

thxs for the road map

On 2/11/17, Robert Osfield <robert.osfield at gmail.com> wrote:
> On 11 February 2017 at 16:56, sduclos <sduclos.cairo at gmail.com> wrote:
>> Perhaps using Vulkan as a backend to OpenGL ES2 (ex.: ANGLE)
>> would not be as involving as rewriting OSG (outch!)
>
> Vulkan is very different to OpenGL/OpenGL ES.  To make the most of
> Vulkan, to give all the flexibility and performance benefits you need
> to build the scene graph with this in mind.
>
> The OSG just can't deliver this, it's an OpenGL scene graph by design,
> it works with and around OpenGL capabilities/limitations.  If you
> attempted to graft Vulkan support you'd have to limit the
> implementation, if you attempted to use a Vulkan backend hidden by a
> OpenGL/ES layer on top of Vulkan you'd loose the benefit of Vulkan,
> you'd be better off just using the OpenGL or OpenGL driver directly.
>
> I think it's crucial to grasp that Vulkan is VERY different to
> OpenGL/ES.  The threading and performance differences in Vulkan will
> change the way we go about implementing graphics.  For instance right
> now the API overhead in OpenGL/ES is so high we have to do lots to
> work batching graphics operations to get best performance. hiding the
> API overhead.  We also are forced to dispatch data into the OpenGL/ES
> fifo single threaded.  For a scene graph to make the most of the new
> capabilities you have to be able thread preparation of the graphics
> data, and now that the API overhead is reduced we open the door to
> doing less batching and returning to a more fine grained scene graph
> in memory that better maps to what is convenient to implement for the
> graphics application rather than try to workaround them doing batching
> even when it hurts other parts of our application development.  With a
> potentially fine grained scene graph we also need to avoid CPU
> overheads associated with that scene graph, otherwise will put a
> performance bottleneck in the application that prevents us seeing all
> the potential of the graphics hardware.
>
> We simple can't achieve the full potential by grafting Vulkan into/or
> adapting it.  We have to understand Vulkan and build around it,
>
> Another consideration is that C++ has moved on, a new scene graph can
> adopt C++11, 14, 17, which due to backwards compatibility issues the
> OSG can't adopt these recent versions of C++. Perhaps it 5 years it
> might be able to do, but not right now if we want to carry the
> majority of the community with us.
>
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>