-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Tracking issue for targeting AMDGPU devices #51575
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
As the work on NVPTX overlap, there could be some common/shared effort. |
I saw that thread! 😄 I have not taken time to read through it, yet, however. Will get to it Soon(TM). I have an example of my progress, using a Rust fork, from before the i/u128 stabilization ecosystem breakage. This example is from this "trivial" program, and in addition to the AMDGPU specific IR, uses a single source Thingy(TM) (I'm in the process of preparing PRs) to compile functions for a different target than the host. mir-hsa-ndarray-example.ll. Warning, it's pretty big! |
As a side note I guess this project could get some development help from AMD or at least some funding from AMD or the AMD subreddit community because rust would be a net improvement for the gpu computing world ! |
This one is merged. |
FWIW this was fixed years ago, nowadays we have the tools to talk about call ABIs. |
Is this ever going to happen? seems the issue has been inactive for some time now. |
In upstream Rust, not likely: I have absolutely no interest in upstreaming anything anymore. I'm (relatively) actively developing my Rust fork which supports AMDGPU however: https://github.com/geobacter-rs. |
Very interesting! I'm cloning and compiling that right now to check it out. Thanks for the info! |
…oli-obk Remove the `abi_amdgpu_kernel` feature The tracking issue (rust-lang#51575) has been closed for 3 years, with no activity for 5.
…oli-obk Remove the `abi_amdgpu_kernel` feature The tracking issue (rust-lang#51575) has been closed for 3 years, with no activity for 5.
…oli-obk Remove the `abi_amdgpu_kernel` feature The tracking issue (rust-lang#51575) has been closed for 3 years, with no activity for 5.
…oli-obk Remove the `abi_amdgpu_kernel` feature The tracking issue (rust-lang#51575) has been closed for 3 years, with no activity for 5.
…oli-obk Remove the `abi_amdgpu_kernel` feature The tracking issue (rust-lang#51575) has been closed for 3 years, with no activity for 5.
Rollup merge of rust-lang#120495 - clubby789:remove-amdgpu-kernel, r=oli-obk Remove the `abi_amdgpu_kernel` feature The tracking issue (rust-lang#51575) has been closed for 3 years, with no activity for 5.
For those subscribed here and still interested in an amdgpu target, I made some progress in compiling for amdgpu with surprisingly few rustc changes. (I got |
…bilee Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while).
…bilee Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while).
…bilee Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while).
…bilee Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while).
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while). try-job: dist-powerpc-linux try-job: dist-powerpc64-linux try-job: dist-powerpc64le-linux try-job: dist-various-1 try-job: dist-various-2 try-job: aarch64-gnu
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while).
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while). try-job: dist-loongarch64-linux
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while). try-job: dist-loongarch64-linux
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while). try-job: dist-loongarch64-linux try-job: dist-loongarch64-muls try-job: dist-powerpc64-linux
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while). try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl try-job: dist-powerpc64-linux
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while).
This issue tracks progress/roadmap for what needs to be done to codegen for targets like AMDGPUs. Personally, I am working on AMDGPU codegen as it would be used for HSA. Specifically, I am aiming for the
amdgcn-amd-amdhsa-amdgiz
LLVM target. Note that I’m still learning, so this issue will likely change as guided by experience.Here are the pieces that will be needed to make this work to a MVP level (ie not providing access to most GPU specific stuff):
librustc_codegen_llvm
aware of LLVM address spaces. #51576. E.g. allocas are in address space 5 for the target triple I mentioned above.amdgpu-kernel
ABI (PR Add theamdgpu-kernel
ABI. #52032).The address space changes are pretty general. However, in order to not require sweeping changes to how Rust is codegen-ed for LLVM, any target must support a flat address space. Flat meaning an addr space which is a superset of all others.
amdgpu-kernel
requires its return type bevoid
. There are two ways I see to do this:rustc
), ie disallow any return type except!
and()
.sret
-like style: promote the return to be an indirect first argument of the function.As I recall, Rust inserts wrapper functions for functions with
extern “abi”
which call the real rust abi function. My current impl went with the magical rewriting, but I think forcing the user to acknowledge this with an error is better long term.Privately, I've made it to errors stemming from # 4 on general Rust code (ie
std
/core
code). See this repo/crate. Regarding virtual function calls, in principle, it’s possible to support, if using HSA, completely GPU side.amdgpu-kernel
s have access to two differenthsa_queue_t
s (one for the host and the device), setup by the GPU’s hardware command processor. When a virtual call is encountered, the trick is to have the GPU write to its ownhsa_queue_t
then wait on the completion signal. Foreign functions can also be supported in this way, by writing to the hosthsa_queue_t
instead.Post-MVP
TBD(TODO) Discuss?
Informational links
The text was updated successfully, but these errors were encountered: