Hello,
I'm currently developing an Android App that uses the Android Studio NDK's Vulkan library.
I've been trying to test my code on a Samsung SM-T510 Tablet (with an ARM Mali G71), it seems like it's having an issue with one of the Vulkan function calls.
The device has no problem calling functions for enumerating physical devices, creating an instance, devices, and buffers.
However, calling vkCreateComputePipeline is returning an error code. (VK_ERROR_INITIALIZATION_FAILED)
I have tried running with both sample and empty kernel code but the issue was still there.
Is there anything that I need to do to enable compute pipelines? Or does this device don't support compute pipelines in the first place?
If it helps, the app is currently on GitHub: the high-level functionality is here:
https://github.com/MangoShip/LitmusTestAndroid/blob/main/app/src/main/cpp/native-lib.cpp
The Vulkan calls are wrapped in "easyvk" library, and the problematic line is here:
https://github.com/MangoShip/LitmusTestAndroid/blob/6b0cb391d7ddc5b04cb2ed9df3b4ed8e7f181cd2/app/src/main/cpp/easyvk/easyvk.cpp#L346
Here is a couple of additional things that I've tried:
Notes:
Thank you!
How are you compiling your SPIR-V modules? They seem to be requesting support for the SPV_KHR_non_semantic_info extension, which older Mali GPUs do not support (very recent Mali drivers should work OK).
The Mali Offline Compiler is correctly reporting "Extension 'SPV_KHR_non_semantic_info' not supported".
I used clspv to compile my SPIR-V modules. Do you know any compiler tools for SPIR-v modules that would work on older Mali GPUs?
Obvious one to try would be to write GLSL compute shaders and then compile with the Khronos glslangValidator
I can confirm that the application works fine on the Pixel 6 with newer drivers, so pretty sure that the problem is the use of "SPV_KHR_non_semantic_info" on devices with older drivers that just don't support this extension. The driver team confirm that drivers older than our r29p0 driver for Bifrost GPUs will fail to compile shaders using it.
The other validation error about use of "SPV_KHR_storage_buffer_storage_class" can be avoided by either enabling the extension, or by requesting a Vulkan 1.1 context (currently VkApplicationInfo is requesting VK_API_VERSION_1_0).
As always, it is highly recommended to learn how to use the validation layers; Vulkan is very unforgiving if the application is using the API out-of-spec.
*EDIT* The spirv-opt tool from https://github.com/KhronosGroup/SPIRV-Tools/ can be used to strip non-semantic info from a SPIR-V module.
HTH, Pete
Adding to what Pete is saying (which I completely second), clspv uses non-semantic instructions to describe the shader<->runtime interface. You will have to either parse these instructions in your application (you can look at https://github.com/kpet/clvk/blob/master/src/program.cpp#L60 for an example of how to do that) or generate a descriptor map using clspv-reflection (https://github.com/google/clspv/tree/master/tools/reflection). Note that this latter path is deprecated.
What you've done in your test application (i.e. assuming bindings are assigned in order to buffer arguments) isn't guaranteed to work. It might for simple cases but is not a reliable solution.
Regards,
Kevin