Skip to content

Conversation

@TinyTinni
Copy link
Contributor

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.

Signed-off-by: Matthias Möller <m_moeller@live.de>
Signed-off-by: Matthias Möller <m_moeller@live.de>
@TinyTinni TinyTinni force-pushed the fix-familyQueue-selection-in-tests branch 2 times, most recently from 89a125f to acbb3d6 Compare January 27, 2026 18:53
// * Queue family 0 and 2 have compute capabilities
// This test assumes:
// * There are at least 2 different Queue families with compute capabilities
// * GPU is able to process parallel shader code across different families
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Incorrect Vulkan API usage

2 participants