On 11 February 2017 at 16:56, sduclos <sduclos.ca...@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@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
