1
$\begingroup$

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 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?

$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – KTM
    Commented Sep 7, 2023 at 13:52

2 Answers 2

1
$\begingroup$

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.

$\endgroup$
5
  • $\begingroup$ So you're taking about queues but i'm asking about queue families $\endgroup$
    – KTM
    Commented Sep 8, 2023 at 13:19
  • $\begingroup$ 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. $\endgroup$
    – pmw1234
    Commented Sep 8, 2023 at 13:38
  • $\begingroup$ 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. $\endgroup$
    – KTM
    Commented Sep 8, 2023 at 13:58
  • $\begingroup$ 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. $\endgroup$
    – pmw1234
    Commented Sep 8, 2023 at 14:10
  • $\begingroup$ Agree with the first statement, and it's possible that this card has an extension for that family such as this 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. $\endgroup$
    – KTM
    Commented Sep 8, 2023 at 14:16
-1
$\begingroup$

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".

$\endgroup$
5
  • $\begingroup$ 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. $\endgroup$
    – pmw1234
    Commented Sep 9, 2023 at 17:17
  • $\begingroup$ 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. $\endgroup$
    – KTM
    Commented Sep 11, 2023 at 13:14
  • $\begingroup$ 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 $\endgroup$
    – pmw1234
    Commented Sep 11, 2023 at 13:48
  • $\begingroup$ 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. $\endgroup$
    – KTM
    Commented Sep 11, 2023 at 13:59
  • $\begingroup$ 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. $\endgroup$
    – KTM
    Commented Sep 11, 2023 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.