Vulkan Queue Families

1
votes

If I get in correctly:

  • queueFamily is a set of queues
  • queue could have more than one queue flag
  • there are 4 types of queue flags(graphics, compute, transfer and sparse binding)

I'm trying to enumerate all informations about a single queue family. First I chceck how many queue families are available, next how many queues every of queue family has, and how many queue flags family supports.

It's enough to know that I have queue family that supports e.g queue graphics flag, or in future I will have to go deeper and check for particular queue from specific queue family?

2
vulkan
By "in future" do you mean in future versions of Vulkan, or do you mean "later" (i.e. further down your program, or later if you decide to use more of the API)? - krOoze
I meant in terms of Vulkan learning and as far as my program goes, but your answer gave me another thing to look at and consider, in future of course - Marek Kowal

2 Answers

1
votes

All queues from a single family have the same properties (the same set of flags). So You don't have to go deeper and check each queue.

But there 3 things You need to remember. Spec guarantees that there must be at least one universal queue which supports graphics and compute operations. Second thing is that different queue families may have the same properties (the same set of flags). And last thing - swapchain presentation (ability to present swapchain image to a given surface) is also a queue family property, but it must be checked through a separate set of queries (functions).

1
votes

or in future

That is basically Q about versioning and extensions.

Major versions are allowed to make any changes (i.e being "uncomapatible"). So you will potentially have to do things differently in the app. But it is conceivable old major versions will still be available alogside new versions.

Minor versions, and extensions are supposed to be backwards-compatible (with notable exceptions). But only on ABI level, so there is no absolute guarantee your program will compile with new header.

That means driver update should not break your already compiled app.

(The notable exceptions are):

  • *Flags returned from Vulkan may have unspecified bits (i.e. bits that are not specified within spec of version you are using with the extensions you have enabled)
  • enums returned from Vulkan may have unspecified values
  • if you actively try to crash your app, such as if( vulkanVersion != 1.0.0 ) crash();
  • the compatibility (obviously?) does not apply to things that are not purely functional (i.e. does not apply to performance, watts, noise, or whatever)
  • if you use any of the new stuff, Vulkan expects you to know all of it — e.g. if your app is mostly Vulkan 1.0, and Vulkan returns flag from Vulkan 1.42 alongside graphics you have not yet bothered to learn, then you later use another flag bit defined by 1.42 in another command, it may interact with the queue flag somehow.
  • any version is allowed to incompatibly fix Spec bug (or what authors decide to consider one)
  • ?