-
Notifications
You must be signed in to change notification settings - Fork 183
Fix family queue selection in tests #448
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Fix family queue selection in tests #448
Conversation
Signed-off-by: Matthias Möller <m_moeller@live.de>
Signed-off-by: Matthias Möller <m_moeller@live.de>
89a125f to
acbb3d6
Compare
| // * 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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 VkQueues 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
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
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.
Closes #445.
This PR will add a check in the
Managerclass 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
TestAsyncOperationsfor a wider range of GPUs. The test will be skipped, if the GPU does not support multiple queue families with compute capabilities.