Fix family queue selection in tests

[TinyTinni]

Closes #445.

This PR will add a check in the Manager class to check, if the given family queues exists and have compute capabilities.
If the selected queue has no compute capability, it can lead to problems e.g. a display freeze on my current AMD Linux system.

The PR also tries to generalize the test TestAsyncOperations for a wider range of GPUs. The test will be skipped, if the GPU does not support multiple queue families with compute capabilities.

[axsaucedo]

This requires not only compute enabled queues, but it actually requres parallel enabled queues. This is something not all GPUs support, would be interesting if there's a way to actually check for parallel enabled queues

[TinyTinni]

You mean GPUs which have the second implementation referenced in the vulkan doc for the queues?

How a VkQueue is mapped to the underlying hardware is implementation-defined. Some implementations will have multiple hardware queues and submitting work to multiple VkQueue​s will proceed independently and concurrently. Some implementations will do scheduling at a kernel driver level before submitting work to the hardware. There is no current way in Vulkan to expose the exact details how each VkQueue is mapped.

(emphasize mine) source: https://docs.vulkan.org/guide/latest/queues.html

[axsaucedo]

No - I mean queues that can actually run workloads in parallel (ref https://towardsdatascience.com/parallelizing-heavy-gpu-workloads-via-multi-queue-operations-50a38b15a1dc)

[TinyTinni]

I think I see the problem. If the queues are not executed in parallel, the test can fail because of the failed timing measurement.

kompute/test/TestAsyncOperations.cpp

Lines 120 to 121 in ec7f816

	// The speedup should be at least 40%
	EXPECT_LT(durationAsync, durationSync * 0.6);

I didn't expect timing measurement in a test. Wouldn't it be better to declare this test as a benchmark? Or copy it and just add this assert to the benchmark. Logically, the test should run fine even on hardware with just serial execution, except that it is probably not that much faster, which doesn't invalidate the correctness.

[axsaucedo]

Correct - indeed it's commented explicitly in the test. I think it'd be valid to mark it as benchmark, but indeed it's not a bug as initially assumed.

We have a benchmark section that it can be moved to - would also be interesting if its possible to identify parallel enabled queues, but previously i had to look at GPU manuals to find out which are the parallel supported queues.

[TinyTinni]

I think there is currently no way on how to get this information. There is some discussion on the vulkan github [1] about it, but it is from 2020 and it is probably not going forward.

What do you think, should we move the whole test to benchmark or alternatively, we add at least a message to the assert. When it fails, at least there will be an explanation to the user on why it fails and that maybe his hardware does not support parallel execution (or the 2 specific queues cannot run in parallel, which can also happen on AMD systems when they are queued next to each other, like someone mentioned in [1]).

Something like

EXPECT_LT(durationAsync, durationSync * 0.6) << "There was no speedup in using multiple queues from different QueueFamilies. Maybe your GPU does not support parallel execution."; 

[1] KhronosGroup/Vulkan-Docs#569

[axsaucedo]

Ok that sounds like a good suggestion!

[TinyTinni]

Added the message to the assertion.

[axsaucedo]

LGTM - thanks