Skip to content
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

Dcomputextra #3683

Merged
merged 1 commit into from
Mar 15, 2021
Merged

Dcomputextra #3683

merged 1 commit into from
Mar 15, 2021

Conversation

bcarneal
Copy link
Contributor

Updating valid_cuda_versions gives access to additional builtins.

The programmer is responsible for adapting to the evolving CUDA semantics but this should not be a breaking change.

@thewilsonator
Copy link
Contributor

Thanks, Waiting on #3684 for test suite to pass. You might have to force push once that goes through to restart the CI

@JohanEngelen
Copy link
Member

Are the valid cuda versions something we can get from LLVM?

500, 520, 600, 610, 620
const std::array<int, 14> valid_cuda_versions = {{CUDA_VALID_VER_INIT}};
500, 520, 600, 610, 620, 700, 720, 750, 800
const std::array<int, 18> valid_cuda_versions = {{CUDA_VALID_VER_INIT}};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As Johan said, it'd be great to get rid of hardcoded stuff like this, to prevent history repeating itself in a few years. There are other missing versions too (530, 320); and with LLVM 11, it looks like no versions older than 200 are supported anymore. - FWIW, in case we cannot derive them from LLVM, I'm in favor of making it the dev's responsibility to provide a valid version rather than pretending to have an up-to-date hardcoded list in the compiler.

@bcarneal
Copy link
Contributor Author

bcarneal commented Mar 13, 2021 via email

@bcarneal
Copy link
Contributor Author

bcarneal commented Mar 13, 2021 via email

@kinke
Copy link
Member

kinke commented Mar 13, 2021

Option 3) is less appealing as I believe it would defer error reporting til run time (when the .ptx file is jitted)

I suggest confirming this first, because it's definitely not what I'd expect. I also expected an error for ldc2 -mtriple=nvptx64 -mcpu=sm_81, but it (AFAICT, LLVM) just prints a warning (6 times in my case...): 'sm_81' is not a recognized processor for this target (ignoring processor). Still, it's probably hard to overlook.

As already stated, I'm for option 3, simply because I care a lot more about power users trying to target the latest dialects (and don't want them to have to hack the compiler to get what they want) than users unable to figure out a correct string - provided there are errors or at least warnings and the help string makes it rather obvious, something like Use '-mtriple=nvptx[64] -mcpu=help' for a list of targetable shader models; e.g., 'cuda-500' corresponds to 'sm_50'.

@bcarneal
Copy link
Contributor Author

bcarneal commented Mar 13, 2021 via email

@bcarneal
Copy link
Contributor Author

bcarneal commented Mar 14, 2021 via email

@thewilsonator
Copy link
Contributor

There is a lot of potentially valuable-at-compile-time GPU information available in this and other llvm files but I think we only really need a stable naming solution.

Those would be exposed via https://dlang.org/spec/traits.html#getTargetInfo though I'm not sure how to go about doing that for multiple GPUs/OpenCL at the same time, but that problem can be solved later.

use of command line examples without -mdcompute-targets=

Short answer is you can't because there is a bunch of metadata that needs to be attached to kernels in the IR for the backend to process is correctly. This is not added with ldc in "CPU mode" when targeting a GPU

clangs --cuda-gpu-arch=

clang does that because they process .cu files twice at the source level, one for the CPU and one for the GPU. ldc does a similar thing except the processing is duplicated in the AST -> IR conversion stage.

My preference would be for an *.inc based off of https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/NVPTX/NVPTX.td . The error messaging functionality would probably have to be reworked but thats fine. It was what worked at the time I wrote it and it was not the focus of my attention, it is far from an optimal way of doing things.

@bcarneal
Copy link
Contributor Author

bcarneal commented Mar 14, 2021 via email

@thewilsonator
Copy link
Contributor

I agree that we should work from the td file in this case so I'd appreciate
someone closing this PR.

Having said that, this is a very non-intrusive change and if this quick-fix enables you to test intrinsics that require more recent processors, then this should go in and a more principled approach can be done later.

@bcarneal
Copy link
Contributor Author

bcarneal commented Mar 14, 2021 via email

@thewilsonator
Copy link
Contributor

I attempted to isolate that commit from the cuda-version issue but my
current git ineptitude resulted in a marooned PR.

Ahh I know that feeling all to well. I think what you want to do here is save the change as a patch an then apply the patch to the branch un question.

@thewilsonator thewilsonator merged commit b3e8b5f into ldc-developers:master Mar 15, 2021
@bcarneal bcarneal deleted the dcomputextra branch March 15, 2021 04:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants