Can someone explain why Vulkans performance is better? But not

>>55661788
>Can someone explain why Vulkans performance is better?
>>55661788
Less overhead than OpenGL. Less legacy crufts.
API designed for low level control, gives developers more refined controls over hardware.

>Also, does it somehow solve opengls problem that not all drivers act the same with the same piece of code?
No.

>>55661788
Shader intrinsic for AMD on Vulkan. A game changer

>>55661788
OpenGL is a very old API designed for workstations. Since it's launch the way GPUs work changed drastically and OpenGL implementations now requires a bunch of logic to translate API calls to actual GPU commands. The fact that implementation details are no longer obvious further hinders performance.

This issue is never going to be solved completely. Sure they can make another OpenGL standard that is representative to the way GPUs work today but in 10 years it will come back to the same situation that it is in now.

Another problem is with shaders. Shaders need to be compiled and for that drivers include a shader compiler. Compilers require a lot of time to develop and require a lot of tuning. A shitty compiler can destroy a shader's performance. Also some companies (Nvidia) as far as I know don't publish information about their shader bytecode/assembly so optimizing shaders for their cards is pretty difficult without collaborating with them. AMD publishes a lot of info about theirs though.

Vulkan comes in to solve those issues. It is an low level API that is very explicit about what commands can you send to the GPU and what do those commands do. A lot of shit from OpenGL like different types of buffers and objects are now just buffers. The global state in OpenGL is now gone, Vulkan is more object based, thank god.

The shader compilation is now completely changed. Vulkan introduces SPIR-V, an open standard for shader bytecode. The GPU drivers only have to convert bytecode to gpu assembly (which is relatively easy) and anyone can write compilers for any language to SPIR-V. This allows for possibly better shader compilers, more shader languages and so on.

With Vulkan being low level and so versatile developers can write their own high level API which is great. Once Vulkan and DX12 become mainstream I imagine a lot of third party high level APIs will be developed for various purposes.

>>55662169
>I imagine a lot of third party high level APIs will be developed for various purposes.
will likely only be rendering engines desu

>>55662192
Sorry for the previous reply
What do you consider to be the difference between a rendering engine and a graphics api?

>>55662192

computing as well, pretty much anything required really

vulkan is perhaps the most autistic API ever created, it is not viable to do anything from scratch with it if you plan on being productive

>>55661788
In OpenGL, all commands are submitted on one command queue.
With Vulkan, you're able to record command lists in parallel on the CPU. This allows you to submit commands to the GPU faster by doing the command list recording on multiple threads on CPU.

Also, the API generally gives you more control over resource management. You get more fine grained control over allocations, and you're in charge of managing resource descriptors.

>>55662169
>>55662367
Thanks a lot for the nice answeres.

One more question:
Would it be possible to implement the opengl api on top of vulkan, so that some kind of universal opengl driver comes out of it? Could be uselfull for free ogl drivers on usecases where maximum performance isn't required