The point of Vulkan wasn't to change the OpenGL API to something else. It was to expose more of what the inner workings of a modern graphics card is, and to remove ambiguity introduced by higher level abstractions used by OpenGL. It is more of a direct translation of what can be done with a graphics driver.
This means that developers (engine writers) who want to can now get a lower level access to what the graphics card can do, and do so in a more deterministic fashion.
Everyone else will be able to use higher-level abstractions that will undoubtedly appear, and those probably be easier to use than OpenGL itself. Best of all, they'll be open source so anyone can dig in and tweak (or understand) something rather than forever depend on some obscure OpenGL behavior no one really understands.
There will be growing pains. The existing engine codebases are heavily based on OpenGL, as are helper libraries. That will need to change. Things won't just be faster overnight. But judging by what I read, in the long run it will be better for everyone involved.
Also one that exposes graphics card mechanics so that higher-level tools can use them more intelligently for optimization purposes.
A good analogy is the RISC transition - implementations were made easier and faster, but as a tradeoff assembly was made much more difficult to program in. The idea being that only a small group of tool-makers with specialized knowledge of the underlying mechanics (in that case compiler developers, in this case engine developers) would ever have to deal with them.
The point of Vulkan wasn't to change the OpenGL API to something else. It was to expose more of what the inner workings of a modern graphics card is, and to remove ambiguity introduced by higher level abstractions used by OpenGL. It is more of a direct translation of what can be done with a graphics driver.
This means that developers (engine writers) who want to can now get a lower level access to what the graphics card can do, and do so in a more deterministic fashion.
Everyone else will be able to use higher-level abstractions that will undoubtedly appear, and those probably be easier to use than OpenGL itself. Best of all, they'll be open source so anyone can dig in and tweak (or understand) something rather than forever depend on some obscure OpenGL behavior no one really understands.
There will be growing pains. The existing engine codebases are heavily based on OpenGL, as are helper libraries. That will need to change. Things won't just be faster overnight. But judging by what I read, in the long run it will be better for everyone involved.