I think it is the combination of an AMD CPU (low IPC compared to Intel) with AMD GPU (unoptimised CPU-heavy OpenGL drivers) that leads to the low performance in OpenMW. In a nutshell:
Intel + Nvidia = fast
Intel + AMD = meh
AMD + Nvidia = meh
AMD + AMD = bad
my main issue is that the game throttles based on CPU performance yet isn't properly utilizing multi-threading
OpenMW uses multi-threading but when the OpenGL thread is the bottleneck, then there is not that much we can do.
I'm thinking of adding back the "reflect X" settings for the water shader, this way you could turn off e.g. NPCs appearing in reflections, which are not that noticable visually, but have a big impact on performance due to the way they're made up of multiple parts. I believe most games use lower detail in reflections, but people won't notice if it's done right.
So about the Vulkan API... now that it's out, any plans??
It is in my (long term) plans. For now I'll wait and see how the Vulkan ecosystem evolves. Good news is that we're in the same boat with hundreds of other people and companies that rely on OpenSceneGraph. I'm curious to see what kind of migration paths people will come up with.
I'm also curious when we're going to see the first OpenGL implementation on top of Vulkan. Being in control of the OpenGL code would be a huge bonus when it comes to mitigating slow OpenGL drivers. And it would potentially allow people to further optimize e.g. by turning off the validation all together, or removing OpenGL features that they don't need (e.g. multiple contexts, which are sort of useless but could have a major performance impact when every OpenGL call you make has to go through some form of thread-local storage first), adding a "command stream" feature like Nvidia's __GL_THREADED_OPTIMIZATIONS (except that it'd be cross-vendor)...
Edit: some more ramblings on
Reddit.
I'm blocked on the debian side anyway due to the OSG situation.