wow, serious fun! thxs for the road map
On 2/11/17, Robert Osfield <robert.osfi...@gmail.com> wrote: > 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 > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
