Vulkan like OpenGL is leaving to the developers the effort to bring their own math library, OS integration and graphical debuggers.
For the rest most of it is hidden behind NDA walls, so you need to sign one to see the codegen examples.
Graphical debuggers on the other hand are useful indeed. LunarG stopped working on Glave: https://github.com/LunarG/VulkanTools/commit/87220f80a643860...
Not sure what happened there. Valve were sponsoring Glave development.
Renderdoc is active (not Linux UI yet however): https://github.com/baldurk/renderdoc
I haven't seen any "lower level control" here, except assembly vs. SPIR-V.
> Vulkan like OpenGL is leaving to the developers the effort to bring their own math library, OS integration and graphical debuggers.
A math library is trivial (and it seems odd that you would claim that not having a math library is a significant downside when your entire premise is "low level, minimalist APIs are better"). "OS integration" and "graphical debuggers" are not part of the API.
> For the rest most of it is hidden behind NDA walls, so you need to sign one to see the codegen examples.
Given that none of the presentation you linked was relevant (it was comparing against pre-DX12, not Vulkan), I doubt that signing an NDA would show me anything more.
What I've been repeatedly asking for is the specific technical advantage that the PS4 API has over Vulkan—in other words, what did Sony do right that Khronos did wrong? I'm interested from the perspective of a compiler writer and a graphics programmer. I haven't heard anything, and at this point I'm inclined to believe that no such thing exists.
Hacker folklore: http://www.catb.org/jargon/html/story-of-mel.html
I don't always agree with what he says, but Mike Acton has some good words and examples of this. https://www.youtube.com/watch?v=GPpD4BBtA1Y - a youtube talk where he talks about working with the compiler. The slides are at http://www.slideshare.net/cellperformance/gdc15-code-clinic In particular take a look at slide 69 and the few following it for an example of things the compiler can't figure out (for various reasons) that we can help it along with.
Where IR-level optimizations are concerned, I agree that you can often do in areas like aliasing (where you, the programmer, have more knowledge than a compiler can easily prove). I'm much less convinced that you can beat a compiler at codegen-level optimizations: instruction scheduling, isel, register allocation, etc.