<p>Some video cards report having multiple transfer queues. This usually correlates directly to hardware. In Vulkan this allows software devs to create addition queues which can be used as needed.</p>
<p>A specialized transfer queue is not the same as a generalized graphics/transfer/compute queue that a lot of cards have, it allows data to be transferred independently of what's going on in the &quot;generic&quot; queue.</p>
<p>So on the one hand graphics commands can be queued up on the graphics queue and at the same time another thread can be queueing data on the hardware transfer queue. Graphics commands can still make forward progress while transfers may be stalled out waiting for data.</p>
<p>At the end of the day this means cards may report more then 1 transfer queue family.</p>
<p>The same can be said about compute queues. In this case the card manufacturer usually reports something like &quot;asynchronous compute&quot; meaning there is a compute queue family that can run at the same time graphics commands are being queued.</p>

CC BY-SA 4.0
2023-09-08T13:19:11.770Z
So you're taking about _queues_ but i'm asking about _queue families_
KTM
CC BY-SA 4.0
2023-09-08T13:38:13.687Z
The two go hand in hand, a system with two hardware transfer queues may report two queue families each of which is only a transfer queue. I made a small edit to help clarify.
pmw1234
CC BY-SA 4.0
2023-09-08T13:58:51.980Z
I appreciate that you understand the use of multiple queues within their specializations. However, the concept of a "queue family" is that "queues in a queue family support the same operations."
If you look at my example, we have two queue families that support the same set of operations. One has 2 queues, the other only 1. I'm asking why this is described as 2 + 1 rather than 3.
KTM
CC BY-SA 4.0
2023-09-08T14:10:42.653Z
But the fact that they are listed separately means they are different. Queue Families are externally synchronized so creating 1 queue from each of these families allows 2 threads to work independently of each other.
pmw1234
CC BY-SA 4.0
2023-09-08T14:16:59.123Z
Agree with the first statement, and it's possible that this card has an extension for that family such as [this](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#VkQueueFamilyVideoPropertiesKHR) and that the capsViewer misses that in its report.
But I believe the second statement is inaccurate: 2 queues from the same family may be used concurrently, or else having, e.g., 16 in one family would be pointless.
KTM
CC BY-SA 4.0
2023-09-07T15:26:54.357Z
2023-09-08T13:38:29.017Z
2023-09-08T13:38:29.017Z
pmw1234
<p>The answer is &quot;Yes, and even for no reason&quot;</p>
<p>The note in the spec says:</p>
<p>&quot;The general expectation is that a physical device groups all queues of matching capabilities into a single family. However, while implementations <strong>should</strong> do this, it is possible that a physical device <strong>may</strong> return two separate queue families with the same capabilities.&quot;</p>
<p>So while this provides no insight into <em>why</em> NVIDIA put two transfer only queue families on this card (and it's possible that it is for a reason which VulkanCapsViewer does not detect,) it is perfectly <em>legal</em> for them to do it.</p>
<p>At the end of the day, I suppose this is because queue families are simply a grouping abstraction, and have no physical or logical consequence: only queues themselves are &quot;real&quot;.</p>

CC BY-SA 4.0
2023-09-09T17:17:29.337Z
See section 3.2 of the spec where it states "A single device may report multiple similar queue families rather than, or as well
as, reporting multiple members of one or more of those families. This indicates
that while members of those families have similar capabilities, they are not
directly compatible with one another." So the answer is no, and for good reason. Because the queues are to be considered incompatible.
pmw1234
CC BY-SA 4.0
2023-09-11T13:14:35.997Z
I read that, but then -- and this may seem crazy -- I kept reading. 5.3.1 has the note quoted above. And, once more, you're answering a different question than the one I'm asking... and rather rudely downvoting a correct answer. I'm going to wait and see if someone knowledgeable has anything more to add.
KTM
CC BY-SA 4.0
2023-09-11T13:48:16.690Z
My only goal with the downvote was to get readers of this answer to take notice that while this answer taken in a bubble could be considered true, but when taken within the full context of the API it is not. There was no hidden personal meaning behind it. I apologize if you took it that way. Good Luck
pmw1234
CC BY-SA 4.0
2023-09-11T13:59:00.850Z
But that's what is misleading: it is true. If we're to resolve the apparent contradiction in the specification we should read it thus: queues that are different necessarily have different queue families; but queues in different queue families are not necessarily different (though they really should be.) The QF paradigm forces you to treat them as though they were different even if they aren't, which is fine.
KTM
CC BY-SA 4.0
2023-09-11T14:02:13.747Z
I'm not suggesting that we should or could do an end-run and combine two queue families that appear similar, I'm only trying to see if there are real world cards that report multiple queue families that appear to be the same -- which there are, and which is legal. I still think that probably the extra transfer queue family _is_ different, but without access to it I can't be sure.
KTM
CC BY-SA 4.0
2023-09-08T15:19:45.840Z
2023-09-08T15:19:45.840Z
KTM
<p>I was trying to find examples of GPUs with more than 3 queue families to see what edge cases programmatic selection of compute and transfer queues might encounter.</p>
<p><a href="https://vulkan.gpuinfo.org/displayreport.php?id=23434#queuefamilies" rel="nofollow noreferrer">This card</a> has six. Two of the extra ones make sense: they look to be specialized for video codec use. But the last queue family is exactly the same as the other &quot;transfer&quot; type family, except with one queue rather than two. Does anyone know the reason for this, or what it means?</p>

CC BY-SA 4.0
2023-09-07T13:52:41.153Z
If someone thinks this is not a proper question, please let me know where it belongs. I must be getting old because SO seems to have become _extremely_ specialized.
KTM
<vulkan>
Can Vulkan Queue Families be separate but identical?
KTM
# Can Vulkan Queue Families be separate but identical?

(Asked by: username_0 on 2023-09-07)

I was trying to find examples of GPUs with more than 3 queue families to see what edge cases programmatic selection of compute and transfer queues might encounter.

[This card](https://vulkan.gpuinfo.org/displayreport.php?id=23434#queuefamilies) has six. Two of the extra ones make sense: they look to be specialized for video codec use. But the last queue family is exactly the same as the other "transfer" type family, except with one queue rather than two. Does anyone know the reason for this, or what it means?

**Tags:** vulkan

> **Comments:**
> **username_0**: If someone thinks this is not a proper question, please let me know where it belongs. I must be getting old because SO seems to have become _extremely_ specialized.  

---

## 2 answers

### Answer by username_1 on 2023-09-07. Score: 1

Some video cards report having multiple transfer queues. This usually correlates directly to hardware. In Vulkan this allows software devs to create addition queues which can be used as needed.

A specialized transfer queue is not the same as a generalized graphics/transfer/compute queue that a lot of cards have, it allows data to be transferred independently of what's going on in the "generic" queue.

So on the one hand graphics commands can be queued up on the graphics queue and at the same time another thread can be queueing data on the hardware transfer queue. Graphics commands can still make forward progress while transfers may be stalled out waiting for data.

At the end of the day this means cards may report more then 1 transfer queue family.

The same can be said about compute queues. In this case the card manufacturer usually reports something like "asynchronous compute" meaning there is a compute queue family that can run at the same time graphics commands are being queued.

> **Comments:**
> **username_0**: So you're taking about _queues_ but i'm asking about _queue families_  
> **username_1**: The two go hand in hand, a system with two hardware transfer queues may report two queue families each of which is only a transfer queue. I made a small edit to help clarify.  
> **username_0**: I appreciate that you understand the use of multiple queues within their specializations. However, the concept of a "queue family" is that "queues in a queue family support the same operations." If you look at my example, we have two queue families that support the same set of operations. One has 2 queues, the other only 1. I'm asking why this is described as 2 + 1 rather than 3.  
> **username_1**: But the fact that they are listed separately means they are different. Queue Families are externally synchronized so creating 1 queue from each of these families allows 2 threads to work independently of each other.  
> **username_0**: Agree with the first statement, and it's possible that this card has an extension for that family such as [this](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#VkQueueFamilyVideoPropertiesKHR) and that the capsViewer misses that in its report. But I believe the second statement is inaccurate: 2 queues from the same family may be used concurrently, or else having, e.g., 16 in one family would be pointless.  

---

### Answer by username_0 on 2023-09-08. Score: -1

The answer is "Yes, and even for no reason"

The note in the spec says:

"The general expectation is that a physical device groups all queues of matching capabilities into a single family. However, while implementations **should** do this, it is possible that a physical device **may** return two separate queue families with the same capabilities."

So while this provides no insight into *why* NVIDIA put two transfer only queue families on this card (and it's possible that it is for a reason which VulkanCapsViewer does not detect,) it is perfectly *legal* for them to do it.

At the end of the day, I suppose this is because queue families are simply a grouping abstraction, and have no physical or logical consequence: only queues themselves are "real".

> **Comments:**
> **username_1**: See section 3.2 of the spec where it states "A single device may report multiple similar queue families rather than, or as well as, reporting multiple members of one or more of those families. This indicates that while members of those families have similar capabilities, they are not directly compatible with one another." So the answer is no, and for good reason. Because the queues are to be considered incompatible.  
> **username_0**: I read that, but then -- and this may seem crazy -- I kept reading. 5.3.1 has the note quoted above. And, once more, you're answering a different question than the one I'm asking... and rather rudely downvoting a correct answer. I'm going to wait and see if someone knowledgeable has anything more to add.  
> **username_1**: My only goal with the downvote was to get readers of this answer to take notice that while this answer taken in a bubble could be considered true, but when taken within the full context of the API it is not. There was no hidden personal meaning behind it. I apologize if you took it that way. Good Luck  
> **username_0**: But that's what is misleading: it is true. If we're to resolve the apparent contradiction in the specification we should read it thus: queues that are different necessarily have different queue families; but queues in different queue families are not necessarily different (though they really should be.) The QF paradigm forces you to treat them as though they were different even if they aren't, which is fine.  
> **username_0**: I'm not suggesting that we should or could do an end-run and combine two queue families that appear similar, I'm only trying to see if there are real world cards that report multiple queue families that appear to be the same -- which there are, and which is legal. I still think that probably the extra transfer queue family _is_ different, but without access to it I can't be sure.  

---

