8 ms·

> No inline PTX (inline GCN/RDNA/GEN is available) If I understand it correctly, that means the compute code is hardcoded into a specific assembly for gpu and

by mnau 2y ago

> No inline PTX (inline GCN/RDNA/GEN is available) If I understand it correctly, that means the compute code is hardcoded into a specific assembly for gpu and to make it work with another card or newer one, you have recompile. Like... Why? What is the problem with using SPIR-V, PTX or plain LLVM IR. If we lived in a monoculture (e.g x86/64 for desktop apps), it would make sense, but there is a plethora of options and one gpu is not assembly compatible next gen.

adrian_b 2y ago
"Inline PTX" is just PTX, and you have already listed PTX among the intermediate representations, which can be independent of hardware, because hardware-specific code will be generated when the program is loaded. Of course, using PTX does not necessarily guarantee backward compatibility, because you may use some PTX features that are supported only on newer NVIDIA GPUs. Nevertheless, inline PTX should continue to work on future GPUs. Perhaps by "hardcoded" you have referred to only a part of your quotation, i.e. to "(inline GCN/RDNA/GEN is available)". In this case I agree with you, but even so, there are enough cases when it is impossible, at least with the current compilers, to obtain the maximum performance allowed by the hardware without using inline assembly language, either for GPUs or for CPUs. Therefore it is good for the high-level programming language to permit the use of inline assembly language, even if this facility should not be abused.
Conscat 2y ago
Inline assembly in shaders exists for basically the same reasons it exists in C++. Hardware gains new features much faster than Khronos standardizes an API for them in SPIR-V, so inline assembly lets you use of them ASAP. You might also want to make optimizations with the assembly if AMD/Intel's SPIR-V compilers aren't doing what you want. Vulkan does make it easy to check which the feature availability of your device, and dispatch different shaders accordingly. That said I've actually never had a reason to use inline assembly in shaders, personally.

by mnau 2y ago

adrian_b 2y ago

"Inline PTX" is just PTX, and you have already listed PTX among the intermediate representations, which can be independent of hardware, because hardware-specific code will be generated when the program is loaded. Of course, using PTX does not necessarily guarantee backward compatibility, because you may use some PTX features that are supported only on newer NVIDIA GPUs. Nevertheless, inline PTX should continue to work on future GPUs. Perhaps by "hardcoded" you have referred to only a part of your quotation, i.e. to "(inline GCN/RDNA/GEN is available)". In this case I agree with you, but even so, there are enough cases when it is impossible, at least with the current compilers, to obtain the maximum performance allowed by the hardware without using inline assembly language, either for GPUs or for CPUs. Therefore it is good for the high-level programming language to permit the use of inline assembly language, even if this facility should not be abused.

Conscat 2y ago

Inline assembly in shaders exists for basically the same reasons it exists in C++. Hardware gains new features much faster than Khronos standardizes an API for them in SPIR-V, so inline assembly lets you use of them ASAP. You might also want to make optimizations with the assembly if AMD/Intel's SPIR-V compilers aren't doing what you want. Vulkan does make it easy to check which the feature availability of your device, and dispatch different shaders accordingly. That said I've actually never had a reason to use inline assembly in shaders, personally.