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!
Hi Mingun Cho,
Please fix you code, anybody can't test your application because you use local path to your spir-v shaders.
Add shaders to assets directory and use Android Asset Manager to load resources
Thank you for trying out the app!
If you check the latest commit of the Github repo, I have resolved the issue that you mentioned. When the app gets launched, all the spir-v shader files should be copied to your local device. Now, the app should be able to use those spir-v shader files to call Vulkan functions.
Please let me know if you experience any other issues.
hi Mingun Cho I can reproduce on Realme Narzo 30 5G with Android 11 and Mali G57 GPU
It is working on Motorola G9 Play with Android 11 and Adreno 610, vect_add_output.txt:
BEFORE: Storing 0 in a[0] Loading a[0]:0 Storing 1 in b[0] Loading b[0]:1 Storing 0 in c[0] Loading c[0]:0 Storing 1 in a[1] Loading a[1]:1 Storing 2 in b[1] Loading b[1]:2 Storing 0 in c[1] Loading c[1]:0 Storing 2 in a[2] Loading a[2]:2 Storing 3 in b[2] Loading b[2]:3 Storing 0 in c[2] Loading c[2]:0 Storing 3 in a[3] Loading a[3]:3 Storing 4 in b[3] Loading b[3]:4 Storing 0 in c[3] Loading c[3]:0 AFTER: a[0]:0 b[0]:1 c[0]:1 a[1]:1 b[1]:2 c[1]:3 a[2]:2 b[2]:3 c[2]:5 a[3]:3 b[3]:4 c[3]:7
It's great to hear you were able to reproduce the issue; let me know if you have any ideas on why it's not working on the ARM GPU or if you'd like me to run any more experiments on my end. Thanks again for your help.
Mingun Cho, first of all, please enable Vulkan Validation Layers usage https://github.com/MangoShip/LitmusTestAndroid/blob/76822ad422ca25db0b297a96ec740506316bf18a/app/src/main/cpp/test.cpp#L17
May be We could see some validation error messages.
I have tried running the tests with Vulkan Validation Layers enabled. However, I wasn't able to see any difference from debug output between the device that executes the code correctly (Qualcomm Adreno 610) and the device that does not. (ARM Mali G71)
I have also examined the different feature sets for both devices using AIDA64. From reading the documentation for differing features, I wasn't able to think of any features I'm using that aren't supported. I have uploaded screenshots of feature sets for both devices here.
Hi Mingun Cho, Try PowerVR GPU, Also We need to ask ARM Mali experts.
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?
Also, the Khronos validation layers correctly identify the problem:
I/vulkan: Loaded layer VK_LAYER_KHRONOS_validation I/VALIDATION: VUID-VkShaderModuleCreateInfo-pCode-04147(ERROR / SPEC): msgNum: 1028204675 - Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-04147 ] Object 0: handle = 0x6eabd14ac0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x3d492883 | vkCreateShaderModule(): The SPIR-V Extension (SPV_KHR_storage_buffer_storage_class) was declared, but none of the requirements were met to use it. The Vulkan spec states: If pCode declares any of the SPIR-V extensions listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (www.khronos.org/.../vkspec.html Objects: 1 [0] 0x6eabd14ac0, type: 3, name: NULL /VALIDATION: VUID-VkShaderModuleCreateInfo-pCode-04147(ERROR / SPEC): msgNum: 1028204675 - Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-04147 ] Object 0: handle = 0x6eabd14ac0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x3d492883 | vkCreateShaderModule(): The SPIR-V Extension (SPV_KHR_non_semantic_info) was declared, but none of the requirements were met to use it. The Vulkan spec states: If pCode declares any of the SPIR-V extensions listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (www.khronos.org/.../vkspec.html Objects: 1 [0] 0x6eabd14ac0, type: 3, name: NULL
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