In the queue chapter:
If an implementation exposes any queue family that supports graphics operations, at least one queue family of at least one physical device exposed by the implementation must support both graphics and compute operations.
This only guarantees a graphics+compute queue exists somewhere, so technically correct code have to enumerate and search every queue family. However, if you run a script (using gpuinfo-vulkan-query) you can see that in practice said family is index 0 in 100% of reported implementations:
Reports with a graphics-capable queue family: 44819
...of those, family 0 is graphics+compute: 44819
Percentage (per report): 100.0%
Reports skipped (couldn't parse queue family schema): 0
I think it would be beneficial for a future maintenance extension to formalize this, e.g:
If maintenanceN is supported, and a physical device exposes a queue family that supports graphics operations, that physical device's queue family with index 0 must support both graphics and compute operations.
This would let developers and tutorials rely on queue family 0 directly, instead of writing (and teaching) enumeration code for a case that doesn't happen in practice. Simplifying initialization code for most developers and letting tutorials rely on it with confidence.
In the queue chapter:
This only guarantees a graphics+compute queue exists somewhere, so technically correct code have to enumerate and search every queue family. However, if you run a script (using gpuinfo-vulkan-query) you can see that in practice said family is index 0 in 100% of reported implementations:
I think it would be beneficial for a future maintenance extension to formalize this, e.g:
This would let developers and tutorials rely on queue family 0 directly, instead of writing (and teaching) enumeration code for a case that doesn't happen in practice. Simplifying initialization code for most developers and letting tutorials rely on it with confidence.