the ptx version, not sm_version or anything else.
as “.version a.b” in ptx code
I think the answer to the titular question is largely yes.
(1) In general, a compiler tends to use the latest PTX version available prior to its release.
(2) I am not aware of a command line option that lets users pick the PTX version
(3) Every given GPU architecture requires a certain minimum PTX version, since the PTX specification evolves to allow access to new hardware features.
(4) I think historically there have been cases where the same compiler would generate different PTX versions depending on which GPU architecture was targeted. But I don’t have a concrete example to point at.
What prompted the question? What issue are you trying to address?
For some reason, I need do several things in following steps;
step1.
a device code should be seperately compile to ptx (as ptx_device) in advance, with cuda_12.0, leading to ptx version=8.0 for ptx_device.
step2.
compile the ptx_device with ptx_global(ptx version=7.7) to cubin, on a target server,with cuda=11.8.
then failed with error code “fatal : Unsupported .version 8.0; current version is ‘7.8’”
An older toolchain obviously does not know how to handle PTX versions introduced after that toolchain came into existence.
That would motivate the existence of my item (2) above: A compiler switch that lets the user specify – within reason – the PTX version generated by the compiler, so the generated file can be processed by components from older toolchains. An example of such functionality would be the ability to force Microsoft Word to export text using a .doc file rather than a .docx file, so older versions of Word that predate the introduction of the .docx format can access that text (with the understanding that not all features available with .docx can be used when .doc is targeted).
As I stated, I am not aware of a command line option for this, but my knowledge of nvcc options is not encyclopedic, and it might therefore be a good idea for you to search the documentation for such a compiler flag. If you cannot find one, you could file a feature request with NVIDIA.
Yep, that’s the core question, args to specify ptx version are not found in documents…
Thanks a lot.
Perhaps always compile to 7.7/7.8 only; or compile to both 7.7/7.8 and 8.0 with the respective nvcc?
Or (“dangerous”) textually replace the version specification in the .ptx files hoping that no advanced features were used.
Good idea, but 1)the environment(nvcc version) is decided by team leader, and 2)replace the code is too dangerous for online service.
Seem the only way is exposition the device code(.cu) to the target server, and then compile to ptx code through the nvcc tool on the target server.
Thx.
Another option could be nvrtc. With it you can compile the cu code at runtime.
You use it like a library instead of running nvcc.
It could be integrated into your actual program.
You can (if needed) encrypt your actual cu code and decrypt before invoking the compilation, as you directly provide the source code instead of by files.
(a skilled bad actor would still be able to extract the source code)
It has similarities with providing the ptx with your program and is easier on the environment.
State what I found as a conclusion:
Stage1. generate ptx code
- ptx generated by nvcc, the ptx version depends on nvcc version
- (not tested, probably)ptx generated by cu function, the ptx version depends on driver version
Stage 2. generate cubin
- cubin generated by nvcc, the ptx version can’t higher than nvcc support
- cubin generated by cu function, the ptx version can’t higher than driver support
| driver | nvcc | ptx version |
|---|---|---|
| 525 | 12.0 | 8.0 |
| 535 | 12.2 | 8.2 |
| 11.8 | 7.8 |