-
-
Notifications
You must be signed in to change notification settings - Fork 79
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
Support for additional vendor GPUs #541
Comments
I am interested, in principle, in an expansion of this library - or at least the idea and the way of doing things in this library - to additional vendors' bespoke GPU use APIs. But there are a lot of caveats. Some of them involve (in no particular order):
I think the best thing to do is for us to have a voice/video chat. If that's possible, please e-mail me so we can set one up. |
Those are good points. Yes, I think it'll be easier to talk on the phone. You're the most knowledgeable about this code, so your insight would be valuable here. I'll include Andrey on the email and that way you will have a user's perspective as well. |
I'm held up at a meeting at work today, and I forget whether we're already at the time we set last week for a meeting. If we are, then - please excuse me, and I'll be in touch ASAP. |
Not a problem. I just hope that you are safe. Our meeting is scheduled for tomorrow Oct 11th 2023 at 11:30am UTC-5 (7:30pm UTC+3). |
(sigh) great... see you tomorrow :-) |
So, it looks like the direction for now will be a fork, to be based off of the soon-to-be-released v0.6.5, and covering some of the core functionality - enough to satisfy the needs of the libintx project. If we find there is wide enough interest and potential resource-commitment, we may consider a more ambitious endeavor. |
Short story
I'd like to contribute support for additional GPUs. I work for AMD, so my priority is to support interfaces for AMD GPUs through the HIP interface, but I see no reason I shouldn't use this opportunity to build a generic enough interface that a different vendor can contribute an implementation for their hardware.
I'm happy to do this, and I'm working with folks involved in the NWChemEx project that would find it extremely useful. And it would give you more users.
Is this contribution something you are interested in and would accept?
Long story
I have been working with some folks adjacent to a scientific code called NWChemEx. There's a lot of dependencies there, but the short story is that one of their dependencies, LibIntX, uses cuda-api-wrappers for marshalling work off to a CUDA backend for running on NVIDIA GPUs. They've requested something similar for AMD GPUs and so I thought I would open an issue here for a few reasons:
I've been interacting with Andrey Asadchev to get his feeling for what would work for him when he's working in LibIntX. I think a good way to think about this is simply to take an existing example. A snippet from the vectorAdd example currently looks like this:
Andrey and I proposed a more generic interface that looks like this:
Basically, everything stays the same but the generic interface makes no references to CUDA specifically. The backend can offload to CUDA, HIP, SYCL, and so on, by simply setting a preprocessor macro to a specific value. Perhaps something like
#define CAW_BACKEND cuda
for CUDA or#define CAW_BACKEND hip
for HIP. This approach would mean that your thin interface layer can stay header-only and anybody using your software could simply set up this macro in their build system and pass it to the compiler with the-DCAW_BACKEND=...
flag.As far as file organisation goes, I think it makes sense to put backend-specific code in their own subdirectories. This will be pretty disruptive. Perhaps an example of what I'm thinking of is like this:
This will require some pretty disruptive and invasive changes to the build system, but this structure at least lends itself to putting a
CMakeLists.txt
file in each vendor-specific backend and having the top-levelCMakeLists.txt
simply include whichever vendor-specific one the user requested when they ask for, for example,cmake -DCAW_BACKEND=cuda ..
orcmake -DCAW_BACKEND=hip
.I'd need to work out the details, but hopefully this paints enough of a picture that you can let me know if this is something you're happy with.
I not only welcome comments and criticisms, but I heavily encourage them.
The text was updated successfully, but these errors were encountered: