Hello guys,
today i saw an interesting talk about DX12 and asking myself if you can do the same in vulkan as presented in this video:
Basically, it presents an way of using different queues on the GPU in parallel for different purposes. I know vulkan has kind of the same concept, with different queues etc., but all examples i have encountered so far just use one graphics-queue.
Can somebody explain me the difference between the concept presented in the video and the actual concept in vulkan?
Thanks
Can somebody explain me the difference between the concept presented in the video and the actual concept in vulkan?
There is an entire chapter in the specification entitled “Devices and Queues.” It explains the [strike]three[/strike]four types of Queues and how they work in Vulkan. Do you have a more specific question about this section of the specification?
all examples i have encountered so far just use one graphics-queue.
Right. Because most examples aren’t nearly complex enough to need multiple different kinds of queues. Especially transfer queues, which deal in memory DMAs. These are primarily used in cases where you’re streaming data asynchronously, and most examples simply have no need to do this.
Okay, one last quesion:
in the video it seems like today’s gpu always have a Copy / Graphic’s and Compute Engine.
My Laptop only reports two Queues. Does this mean one of the queues have at least two of the already mentioned functionality?
There’s only one GRAPHICS+COMPUTE queue per ICD guaranteed.
Apart from that, you have whatever you have. That is whatever is reported by vkGetPhysicalDeviceQueueFamilyProperties.
[QUOTE=Twanks123;40877]Okay, one last quesion:
in the video it seems like today’s gpu always have a Copy / Graphic’s and Compute Engine.
My Laptop only reports two Queues. Does this mean one of the queues have at least two of the already mentioned functionality?[/QUOTE]
It’s always best to refer to the specification, rather than making inferences based off of a video. Especially when its for a different API. And even moreso if it’s from a presentation by AMD. Or NVIDIA.
They’re not exactly unbiases sources…
Also, it’s important to understand the difference between a queue family (aka: a type of queue) and an actual VkQueue object. Your device may report two queue families, and for one or more queue families, it may offer the ability to create multiple queues from that family.
The functionality that a queue offers is defined by the queue family that it is created from.
For example, NVIDIA frequently offers 2 queue families: one family that supports everything and one transfer-only queue (it can’t even handle sparse stuff). The thing is, you can create up to sixteen independent queues of the “do anything” family, but only one transfer queue.
Also, note that in Vulkan, a queue that supports GRAPHICS does not necessarily support COMPUTE. However, if it supports one of those operations, it also supports TRANSFER.
So what’s the point of having a transfer-only queue family, if NVIDIA supports 16 independent queues from the same family? That should be a hint that doing transfer operations on the graphics/compute queues will likely be less efficient than using the transfer-only queue. The transfer-only queue family thus represents a completely separate piece of hardware from the graphics/compute queues.
Thanks again Alfonse!
I have read the spec more than one times, but its so much of new information for me, i am still forgetting lots of things.
With your answer i fully understand it now =)
[QUOTE=Alfonse Reinheart;40879]
So what’s the point of having a transfer-only queue family, if NVIDIA supports 16 independent queues from the same family? That should be a hint that doing transfer operations on the graphics/compute queues will likely be less efficient than using the transfer-only queue. The transfer-only queue family thus represents a completely separate piece of hardware from the graphics/compute queues.[/QUOTE]
Have you tried that yet on Nvidia hardware? I haven’t tried it yet myself but I’ve been curious if there’s a significant advantage to transferring with the transfer-only queue family versus one of the 16 general purpose queue families on Nvidia hardware.
Ah i have another question
If i use two queues from one queue family (e.g. from the mentioned “do anything” family). What is the advantage of this? Why should i do this?
Mostly convenience. You don’t have to transfer ownership of EXCLUSIVE Images and Buffers. And you can have rendering and compute in the same command buffer.
[QUOTE=Twanks123;40895]Ah i have another question
If i use two queues from one queue family (e.g. from the mentioned “do anything” family). What is the advantage of this? Why should i do this?[/QUOTE]
Because, while the queues are separate, they will process commands independently of each other.
You could issue rendering commands on one and compute commands on another. The compute commands might be destined for the next couple of frames, so it doesn’t matter when it finishes relative to the rendering commands. Their processing will interleave with the rendering commands, but neither will necessarily wait for the other.
Think of a queue family like a C++ class. It’s a prototype; it has certain behavior. A VkQueue is an instance of that class. Each instance has the same functionality, but acts independently of the other.
The analogy breaks down a bit, since there’s a limit to the number of VkQueues you can create from a queue family.
The video offers a lot of ideas. Which one in particular are you talking about?
Also, there are plenty of videos out there exclusive to Vulkan. The GDC series is pretty good, and the SIGGRAPH series has good info. But the Vulkan Dev Day presentations are about as comprehensive as you’re going to get with Vulkan.
