radv is one of the ones I'm referring to, it's open source so we can see the tricks they use. One example: it spawns a thread behind your back in order to execute command buffers in order to make the queue submit appear nonblocking (or at least fast). This is completely contrary to the spirit of the Vulkan spec which deliberately doesn't provide any convenience mechanisms for things like callbacks on command buffer completion, precisely because these would require runtime threads to be around. The user has no control over this thread, including where it spawns or its priority (how could it, when it's an implementation detail of the driver?) nor can they take advantage of this knowledge to improve synchronization on the CPU side (e.g. by removing external synchronization around queues).

Contrast this with the situation on Metal (explicit runtime that spawns threads, and explicit callbacks to be able to take advantage of that) or DirectX 12 (explicit runtime that works for the average case, with extremely fine grained control provided over the threading model, priorities, etc., including being able to turn them off completely if you really need it). Both of these are clearly much better models because they are actually exposing the detail that seems obvious in hindsight (applications need queue submission to be nonblocking) and are able to provide much more flexible, efficient, and useful APIs as a result.

By leaving everything up to the user, Vulkan in practice ends up underperforming its competitors unless the drivers patch up the work--at which point you have the unfortunate situation where you have people targeting a low-level API running on a high-level runtime. It's this, not some dumb digression about extensions, that IMO make Vulkan kind of disappointing--it's definitely not a failure, but it could've been much better than it was.

As long as it doesn't violate the spec, I'd look at actual performance results of it. I.e. if it interferes with usage or creates some kind of performance degradation for the applications, then it's indeed a problem. Otherwise this requirement should have been an explicit part of the spec.

I.e. I'd imagine if this is a real problem, there should be some RFC for the updated version of the API where this is prohibited or some requirements are added about how to control it.

It creates a performance degradation for applications that are correctly using Vulkan. And from conversation with Khronos people they do definitely consider this a failure (either of the spec or of the driver); among other things, it makes benchmarking rather difficult if new threads are spawning constantly as you submit command buffers. But my assertion (backed up by radv benchmarks) is that effectively nobody can use Vulkan APIs "correctly" which is why implementations like that are helpful in practice.

Then I'd expect someone to actually propose to address this in the future versions. Question is how easy they can do that, given there is some backward compatibility guarantees I suppose.

I'm not sure what their approach for that is. May be they break it at some point and then the driver can offer more knobs for such features to be optional or behave differently in the newer versions.