[osg-users] Thoughts on Vulkan

[Max Maslov]

Any news about Vulkan in OSG?

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

[Robert Osfield]

Post by Max Maslov
Any news about Vulkan in OSG?

I continue to believe it is impractical to support Vulkan directly
within the OSG, while technical possible it would require a massive
rewrite which would break backwards compatibility and require major
changes to OSG applications.

The path I am planning to develop a another scene graph that directly
supports Vulkan, and have support for integrating the OSG and this new
scene graph. The intention behind this would be to make it possible
for OSG applications to be migrated across incrementally as well as
provide a leg up to the new scene graph by giving it access to OSG
loaders etc.

Robert.

[sduclos]

Hi Robert,

Perhaps using Vulkan as a backend to OpenGL ES2 (ex.: ANGLE)
would not be as involving as rewriting OSG (outch!)

Sylvain.

Post by Robert Osfield

Post by Max Maslov
Any news about Vulkan in OSG?

I continue to believe it is impractical to support Vulkan directly
within the OSG, while technical possible it would require a massive
rewrite which would break backwards compatibility and require major
changes to OSG applications.
The path I am planning to develop a another scene graph that directly
supports Vulkan, and have support for integrating the OSG and this new
scene graph. The intention behind this would be to make it possible
for OSG applications to be migrated across incrementally as well as
provide a leg up to the new scene graph by giving it access to OSG
loaders etc.
Robert.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

Post by sduclos
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.

[sduclos]

wow, serious fun!

thxs for the road map

Post by Robert Osfield

Post by sduclos
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
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Max Maslov]

Thanks for answer. So, when you plan to start developing of Vulkan scene graph? Maybe after 3.6? :)

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

[Robert Osfield]

Post by Max Maslov
Thanks for answer. So, when you plan to start developing of Vulkan scene graph? Maybe after 3.6? :)

My plan is complete the OSG-3.6 stable release and then move to the
new scene graph.

My intention is for the core of the new scene graph to be API
agnostic, then have backends for Vulkan, OpenGL and OpenGL ES.

The focus will be primarily on Vulkan in terms of making sure the
design of the scene graph fully leverage what Vulkan is capable of.
Until we get an implementation going I can't say exactly how this will
impact the OpenGL/ES side. The new scene graph needs to be relevant
to application developers for the next 15+ years, taking over the
"mantel" from the OSG is this respect ;-)

Robert.

[Nickolai Medvedev]

Hi, Robert.

Transition to Vulkan will be difficult. Partly because, that all graphics is
based on shaders. But I think that the new system for OpenSceneGraph - it is good.
I will try to help, as far as I will be able.

Cheers,
Nickolai

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

[Robert Osfield]

Post by Nickolai Medvedev
Transition to Vulkan will be difficult. Partly because, that all graphics is
based on shaders. But I think that the new system for OpenSceneGraph - it is good.
I will try to help, as far as I will be able.

I've have been putting several ideas that I developed for the new
scene graph into the OSG, this will be in 3.6;-)

[Nickolai Medvedev]

Hi, Robert.

And it is good that you have ideas.
First of all, it is necessary to refuse opengl fixed pipeline.
It is necessary to create shader-based lighting system.
I already try to create deferred rendering with various models of lighting
(phong, cook-torrance, etc.), but now it isn't a lot of time, therefore
work has stopped.

Cheers,
Nickolai

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

[Nickolai Medvedev]

So, Robert, if you if you are going to use C++11, it means that
OpenThreads won't be used anymore(use std::thread)?

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

[Robert Osfield]

Post by Nickolai Medvedev
So, Robert, if you if you are going to use C++11, it means that
OpenThreads won't be used anymore(use std::thread)?

One of the reasons to use C++11 is avoid the need to external
dependencies such as OpenThreads.

However, C++11 threading is still a bit too primitive for serious
threading work as there is no support for processor affinity so we'd
need to implement this.

Robert.

[sam]

Hi Guys,

Sorry to hijack this thread a little bit. What would you guys consider the
best source of information for Vulkan? Primarily focusing on the
fundamentals.

Thanks, Sam

Post by Robert Osfield

Post by Nickolai Medvedev
So, Robert, if you if you are going to use C++11, it means that
OpenThreads won't be used anymore(use std::thread)?

One of the reasons to use C++11 is avoid the need to external
dependencies such as OpenThreads.
However, C++11 threading is still a bit too primitive for serious
threading work as there is no support for processor affinity so we'd
need to implement this.
Robert.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Chris Hanson]

​There aren't many sources, to be honest.

If you like dead-tree type material, I was tech reviewer on this book:
https://www.amazon.com/Vulkan-Programming-Guide-Official-Learning/dp/0134464540


It has good material, but the scope of the task is daunting no matter how
you approach it.

[Chris Hanson]

I just wanted to mention that Jeremy ("osgWidget", "osgCairo", "osgPango")
has been working on a scene graph named Heirograph with similar design
goals. There is already an OpenGL ES2 backend implementation and our goal
is, similar to Robert's, to make a Vulkan and a desktop non-FFP OGL3+ or
OGL4 backend as well.

It is based on modern C++11 and has a basic model loader based on Assimp.

It can even already render some things. ;)

There is no OSG-to-Heirograph loader/converter (yet), but Paul Martz
already did one of those with his earlier "JAG" OSG3+ scenegraph project,
so it wouldn't be difficult.

[Rafa Gaitan]

Hi,

Additionally to the book you can find very good tutorials and references
here: https://vulkan-tutorial.com/

Robert, I'm quite interested and I'll be glad to help in the development of
the new scenegraph :). I have some ideas for the new library regarding the
similarities between Vulkan and OpenCL which might be interesting to study.

Chris, is there any public repository where we can take a look to
Heirograph? ;)

Best regards,
Rafa.

Post by Chris Hanson
I just wanted to mention that Jeremy ("osgWidget", "osgCairo", "osgPango")
has been working on a scene graph named Heirograph with similar design
goals. There is already an OpenGL ES2 backend implementation and our goal
is, similar to Robert's, to make a Vulkan and a desktop non-FFP OGL3+ or
OGL4 backend as well.
It is based on modern C++11 and has a basic model loader based on Assimp.
It can even already render some things. ;)
There is no OSG-to-Heirograph loader/converter (yet), but Paul Martz
already did one of those with his earlier "JAG" OSG3+ scenegraph project,
so it wouldn't be difficult.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

Post by Nickolai Medvedev
And it is good that you have ideas.
First of all, it is necessary to refuse opengl fixed pipeline.

I don't understand your use of "refuse" here?

For OSG-3.6 my plan is to attempt to have an automatic mapping of old
fixed function pipeline state to shader based state.

Post by Nickolai Medvedev
It is necessary to create shader-based lighting system.

That all depends upon your needs and the scene graphs you are using,
this applies to the OSG or any other scene graph.

Robert.