11 ms·
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 degra
by shmerl 5y ago
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.
- Jweb_Guru 5y agoIt 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.
- shmerl 5y agoThen 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.