As for Async; firstly it seems that pre-Pascal forget it on NV. If they were going to enable things to work sanely on those cards they would have done so by now

It's not so much limited to async compute, but to compute and transfers in combination alltogether it seems.

I can confirm that from my immediate experience with using Blender (which on NV uses CUDA) on a desktop computer with a Maxwell GPU in comparison to my notebook which only has the Skylake CPU's integrated graphics chip.

Yeah, Blender on a notebook, and setting the 3D viewport to "render", what a fucked up idea, this cannot possibly work. Guess what, it works way better than on the desktop computer with dedicated GPU.

Now looking at the performance counters shown by process explorer, it turns out the Maxwell has two shader units busy on average (two!) whereas the cheap integrated Intel GPU has them all 95-100% busy. So I guess if the GPU does not spend its time doing compute, the time must go into doing DMA and switching engines between "transfer" and "compute". Otherwise I couldn't explain why the GPU usage is so darn low.

Now, since this is not an entirely unknown issue, I would seriously expect Pascal schedule/pipeline that kind of mode switching much better, or even do it in parallel seamlessly (I think I have read something about them adding an additional DMA controllers at one point, too, though I believe that was even for Maxwell -- would make seem on yet older generations it's still worse?).

Although it's true that Vulkan performs much faster than OpenGL, I don't think OpenGL is going anywhere anytime soon. Now, engines such as Unreal and Unity will perform Vulkan under the hood, but nobody in their right mind will code in Vulkan (have you seen this "simple" Hello Triangle?). However, I think it'll be interesting to see what happens. Who knows, maybe we'll all end up coding with Vulkan. Computers will continue to get faster, but so will our ambitions, so Vulkan seems like the new future of graphics processing, but OpenGL will be here to stay due to its "simplicity" (at least compared to Vulkan). :D

nobody in their right mind will code in Vulkan (have you seen this "simple" Hello Triangle?).

This isn't a triangle example, it's a simple rendering engine for triangles with a RGB colour at each vertex that has an easy to find hardcoded triangle in the middle as an example of the example:

// Setup vertices		std::vector<Vertex> vertexBuffer = 		{			{ {  1.0f,  1.0f, 0.0f }, { 1.0f, 0.0f, 0.0f } },			{ { -1.0f,  1.0f, 0.0f }, { 0.0f, 1.0f, 0.0f } },			{ {  0.0f, -1.0f, 0.0f }, { 0.0f, 0.0f, 1.0f } }		};		uint32_t vertexBufferSize = static_cast<uint32_t>(vertexBuffer.size()) * sizeof(Vertex);		// Setup indicesstd::vector<uint32_t> indexBuffer = { 0, 1, 2 };

In example code, the priority is calling the API properly, not good abstractions (which would be confusing).
 
EDIT: quoting loses links. The "triangle example" is https://github.com/SaschaWillems/Vulkan/blob/master/triangle/triangle.cpp from the well known Vulkan examples repository by Sascha Willems.

I think that's not what these quotes (both towards Vulkan and modern GL) are meant to be or what they should be read as.

Sure, the draw-triangle code is concise, straightforward, clear (both in GL4 and Vulkan), but it takes about 100 lines of code to even get a context which can do anything at all set up in GL, and about three times as much in Vulkan. Plus, it takes like half a page of code to do what you would wish to be none more "CreateTexture()" or the like.

Hence the assumption "no sane person will...". Almost everybody, almost all the time, will want to be using an intermediate library which does the Vulkan heavy lifting.

Hence the assumption "no sane person will...". Almost everybody, almost all the time, will want to be using an intermediate library which does the Vulkan heavy lifting.

This looks to be a good assumption... When you have a real good low-level library, we can foresee new higher-level libraries that will provide more easy means. But then we might end with a plethora of libraries, for sure not compatible between themselves... Each of them having their good and bad things.

It's also possible for OpenGL implementations and even Direct3D to have future releases based on Vulkan... But maybe I'm too wrong here.