AFAIK, the point of Vulkan is to get to modelling the hardware as possible. It's not even supposed to be a high-level API but allow efficient access to today's GPUs.
OpenGL is an abstract state machine and it requires a great deal of effort to convert that state into what today's GPUs are actually capable of efficiently handling. Getting that triangle onto the screen in OpenGL is maybe 20 lines of code but you will have 200,000 lines of code in the OpenGL driver translating the commands into the actual configuration of the hardware unit. And if you want to draw 2 million triangles you will have to work hard to work around the overhead introduced by the OpenGL implementation.
Then again, OpenGL can be reimplemented on top of Vulkan for end-developers and more complex game engines will be written against Vulkan directly, and then people will work on those instead of writing direct Vulkan code. Once you get the building blocks right you can build on top of them layers of abstraction that suit what you need.
This is in contrast to the current situation where the abstractions are fixed and don't necessarily suit the end-developer nor the driver developer. Today you need to implement your game or graphics engine abstraction (which you will use yourself) in terms of OpenGL (requiring lots of tricks), then the OpenGL driver has to implement OpenGL in terms of the actual hardware (again, requiring a lot of clever trickery to handle and transform the state efficiently) and as a result the pixels will show up on the screen but at the cost of a potentially huge overhead which could be introduced somewhere along the route.
Yup. The way I understand it is that graphics pipelines today (maybe always) are quite different from the procedural API that OpenGL provides. That mismatch causes all sorts of problems, for example that using the OpenGL APIs "naturally" can be extremely inefficient, whereas trying to access the GPU pipeline naturally is really convoluted and you have to get it just right in non-obvious ways.
The structure of the GPU pipeline appears to be sufficiently settled that we can now expose it more directly. That way, talking to the GPU in a way that's natural for the GPU is at least straightforward, even if it's arduous.
It seems like you should now be able to build APIs that are both at a higher level and not in conflict with how the hardware actually works.
Different GPUs have different machine codes, Vulkan is abstracting away the differences, but tries (like C) to be simple abstraction close to the real thing.
OpenGL is an abstract state machine and it requires a great deal of effort to convert that state into what today's GPUs are actually capable of efficiently handling. Getting that triangle onto the screen in OpenGL is maybe 20 lines of code but you will have 200,000 lines of code in the OpenGL driver translating the commands into the actual configuration of the hardware unit. And if you want to draw 2 million triangles you will have to work hard to work around the overhead introduced by the OpenGL implementation.
Then again, OpenGL can be reimplemented on top of Vulkan for end-developers and more complex game engines will be written against Vulkan directly, and then people will work on those instead of writing direct Vulkan code. Once you get the building blocks right you can build on top of them layers of abstraction that suit what you need.
This is in contrast to the current situation where the abstractions are fixed and don't necessarily suit the end-developer nor the driver developer. Today you need to implement your game or graphics engine abstraction (which you will use yourself) in terms of OpenGL (requiring lots of tricks), then the OpenGL driver has to implement OpenGL in terms of the actual hardware (again, requiring a lot of clever trickery to handle and transform the state efficiently) and as a result the pixels will show up on the screen but at the cost of a potentially huge overhead which could be introduced somewhere along the route.