NVPTX: Drop support for old architectures and old ISAs#152443
NVPTX: Drop support for old architectures and old ISAs#152443kjetilkjeka wants to merge 1 commit intorust-lang:mainfrom
Conversation
|
Some changes occurred in src/doc/rustc/src/platform-support cc @Noratrieb |
|
r? @jackh726 rustbot has assigned @jackh726. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
r? @ZuseZ4 |
|
@rustbot label +O-NVPTX |
|
|
||
| const NVPTX_FEATURES: &[(&str, Stability, ImpliedFeatures)] = &[ | ||
| // tidy-alphabetical-start | ||
| ("sm_20", Unstable(sym::nvptx_target_feature), &[]), |
There was a problem hiding this comment.
@kulst I assume it's correct to just remove the features for the things we do not support anymore?
This comment has been minimized.
This comment has been minimized.
af90fab to
192c99f
Compare
This comment has been minimized.
This comment has been minimized.
192c99f to
a516a55
Compare
This comment has been minimized.
This comment has been minimized.
a516a55 to
5f88388
Compare
This comment has been minimized.
This comment has been minimized.
4cbf1bb to
9026a42
Compare
|
Changing a target baseline officially doesn't require a blog post: https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#other-kind-of-target-changes But since it's afaik the first time that we raise it for a GPU target and since nvptx is Tier 2, would you mind to still write one, so that we could merge it simultaneously? https://blog.rust-lang.org/2023/09/25/Increasing-Apple-Version-Requirements/ and https://blog.rust-lang.org/2025/08/19/demoting-x86-64-apple-darwin-to-tier-2-with-host-tools/ are two related examples, but there are more if you want some inspiration. Just a more user-friendly, short version of your MCP. Something motivating the change, mentioning the new behaviour, and saying that we will likely raise it further in the future, would be enough. |
|
So this drops support for Pascal (10 series, P100), while keeping support for Volta (V100) and Turing (16 and 20 series)? Perhaps including that information in the docs would be helpful. |
9026a42 to
e04ea32
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
e04ea32 to
dc1bd5a
Compare
|
With regards to blogpost, is something like this acceptable? rust-lang/blog.rust-lang.org#1810
Yes. I linked to the document by Nvidia listing all their GPUs as it will quickly become very verbose to explicitly list a lot of GPUs. Let me know if you think it's easier to get hold of this information with these changes. Since the branch date for 1.95 was approaching I decided to instead wait for 1.96. The version is stated to be 1.96 in the docs and blogpost right now and we should have plenty of time for that branch date. |
| While the compiler accepts `#[target_feature(enable = "ptx80", enable = "sm_89")]`, it is not supported, may not behave as intended, and may become erroneous in the future. | ||
|
|
||
| ## Minimum SM and PTX support by Rust version | ||
| Old hardware architectures and PTX ISA versions are periodically dropped support for. This table shows the minimum supported versions per Rust version. |
There was a problem hiding this comment.
Nit: Might just be because I'm not native, but it reads a bit awkward to me. Does
Support for old hardware architectures and PTX ISA versions is periodically dropped.
sound better?
| }, | ||
| ); | ||
|
|
||
| // This is needed to ensure that we don't use PTX ISA versions that we do not support |
There was a problem hiding this comment.
I just looked up the ptx-release-history link from this PR to verify that we don't need to handle sm_80. Can you make it slightly more explicit for the next reader by saying that sm_{70,72,75} would default to ptx60, which is unsupported, whereas sm_80 would default to ptx70, which is supported?
| None | Some("sm_70") | Some("sm_72") | Some("sm_75") | ||
| ) | ||
| { | ||
| rust_features.push((true, "ptx70")); |
There was a problem hiding this comment.
This one is added after the sorting above, so it will come behind all other ptx versions.
Normally the largest would be ordered to come last and naturally be selected, but I think here you would overwrite the user selection for these sm, if the user selected a higher ptx, or?
This is the implementation of this MCP
I believe it was said that no FCP was needed, but if that is incorrect then the FCP is anyway scheduled to finish in 2 days so it can in any case be merged then.