Python wrapper of vkFFT for Vulkan backend

[yves-surrel]

I am an end-user needing GPU speed for my computations in Python. Until today, I have been pretty satisfied with the excellent pyOpenCL bindings and clFFT library. I recently discovered vkFFT (the name of which hides the fact that there are other backends than Vulkan). Vincent Favre-Nicolin created the Python bindings of vkFFT for the CUDA and OpenCL backends.

I began to play with interfacing vkFFT Vulkan backend to Python , using Vincent's existing work. It seems relatively easy to rework vkfft_opencl.cpp to create a vkfft_vulkan.cpp file that should be convenient. My problem is to rework opencl.py as vkFFT expects things like VkBuffer, VkQueue and VkCommandPool objects that seem not to be exposed by kompute.

Is there a way to get the required objects (e.g. the VkBuffer object from a Tensor object), or should I disregard kompute to switch to the much lower level Realitix Vulkan bindings ? This would be a pity, as Kompute seems more easily usable.

[axsaucedo]

Thanks for the question @yves-surrel , I would be extremely interested to add vkFFT into Kompute and integrate it - I don't think currently there are plans to expose every underlying Vulkan API object through Kompute Python interface as ultimately the objective of Kompute is to provide an abstraction, although the C++ component would make more sense to expose it so happy to explore that. We recently had an example port of a neural network with only a couple of lines of code (https://github.com/EthicalML/vulkan-kompute/tree/master/examples/neural_network_vgg7) so it may be something interesting to try to implement this as an Operation / Kernel. If you are interested I would be very keen to explore this further.

[yves-surrel]

Sure that a Kompute OpFFT would interest plenty of people. Probably OpenCL is reaching the end of its life, so switching with minimum efforts to a more modern framework is really desirable.

[axsaucedo]

@yves-surrel just following up on this, would you be interested on giving this an initial go?

[yves-surrel]

Well, I am embarrassed… I lack the knowledge to do so. I am rather an end user, and unfortunately I would lack the time to develop, being in the process of making the software product for my startup. However I certainly would contribute to testing on my hardware (MacOs MBP and MacMini M1, PC + Linux)

…

Le 12 sept. 2021 à 10:33, Alejandro Saucedo ***@***.***> a écrit : @yves-surrel <https://github.com/yves-surrel> just following up on this, would you be interested on giving this an initial go? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#229 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQM3HFOYKJAMJVJFJPP4XTUBRQXFANCNFSM46MLP4QQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[axsaucedo]

No worries at all, I assumed from the suggestion that you may have some insights on creating an interface, which would be awesome as the vkFFT project is awesome, but let's keep this issue open to see if it can be picked up in the near future. For the meantime any contributions to increase the function and code coverage in the C++ codebase is certainly appreciated, but given your current committments it seems that's something that could be explored if relevant in a potential future. Thanks.