That's a big "NOT", though, for such subtle semantics and IMO more confusing than helpful. It's by the same people, for the same thing. It's set to replace OpenGL in the long term, no? I'd say that the only reason not to call it a successor would be if OpenGL offered features that Vulkan can't provide which I don't think is the case.
Historically there's been a big divide between what the game engine vendors vs the CAD vendors want out of the OpenGL standard, so this split is a good thing for both. The existing OpenGL systems stick around without dragging game performance down with them.
Why isn't it a subset of OpenGL, then? Maybe that's what's confusing?
It sounds like the most typical usage would be to implement things in OpenGL and then do a few hardcore optimization tasks in Vulkan. Why not add that access to OpenGL and put a "use at your own risk" disclaimer in front of it? Or are they so incompatible you have to write your entire graphics code in either but never both?
> It sounds like the most typical usage would be to implement things in OpenGL and then do a few hardcore optimization tasks in Vulkan.
No. You can't really mix the two. The semantics are wildly incompatible.
Roughly: the OpenGL API models an ideal graphical state machine and does an enormous amount of work to retain state and paper over the fact that a modern GPU works nothing like the ideal state machine.
Vulkan does literally the opposite. Stateless calls that let you control low-level GPU resources, and nothing more. You can't really make a bunch of Vulkan calls and then an OpenGL call that will blow away all your buffers, generate shader code dynamically without telling you, and do a billion other things "magically", and make it all work. The two fundamentally different approaches are in opposition.
They're implemented by different drivers, as well. The Vulkan driver is intentionally very thin, stateless, and consequently multithreading-friendly. The OpenGL driver is enormous (including everything up to and including a GLSL compiler), stateful, and consequently very hard to use from more than one rendering thread. This is a big source of performance issues, since it means draw calls are inherently limited to a single thread, which is a big limiter for games.
You can't have the two different models, from two different drivers, talking to the same hardware at the same time. It would be pointless even if you could -- you use Vulkan so you can thread draw calls. OpenGL destroys that.
I think this answers your first question, too:
> Why isn't it a subset of OpenGL, then? Maybe that's what's confusing?
You lose the thin & multithread-able advantages of Vulkan if you keep OpenGLs higher level stateful semantics around.
It's been tried, many times, in different OpenGL versions, over the years, to create a low-level performant subset. The conclusion has always been the same -- retaining compatibility with higher level calls hampers what you can do in your new low-level calls (need to constantly sync state and expect that at any time a call could have been made that changed any number of internal state variables == lots of checks and lots of locks). Your draw call ceiling is always low and CPU bound because the locks kill threadability
