I certainly can’t provide guarantees of compiler behavior, especially not future behavior. The recommendation given by njuffa seems reasonable to me, except it puts you back into the mode of asking how to get max supported PTX version, and I don’t know how to do that without your own lookup table, and even that doesn’t address the future case. Given this, I see maybe two possibilities:
- Build your own lookup table, of driver version range and supported PTX version, and acknowledge that this still doesn’t cover the future
- Given that you are using “stable” PTX, choose a high enough PTX version to make future compilation changes less likely, and use that as your default choice.
I will say this: if I have a PTX program, and the PTX is compatible, say, with both PTX version 5 and also PTX version 6, I would be very surprised if there was any difference in the generated SASS when generated by a driver that understands both PTX 5 and PTX 6. I make this statement independent of the target. However, it’s just a statement of my opinion, not a guarantee. I can’t imagine why a driver that knows how to do something with PTX that it understands, do something differently because it was marked version 5 instead of version 6. I cannot imagine why that would make a difference for SASS generation. But I don’t know everything. Clearly, if you are going to target a particular device compute capability, however, you must specify at least a PTX version that recognizes that compute capability. That is what I mean by “independent”, here. If the target compute capability is fixed, and supported, I don’t know why varying PTX version should matter for SASS generation.
You could also file a bug to request a new feature (report GPU driver max supported PTX version). Just to be clear though, that is unlikely to show up as something like
CU_DEVICE_ATTRIBUTE_PTX_VERSION_MAJOR because its not a device attribute.
(with respect to the advice given by njuffa, the only change I would suggest is for item 1 Specify the latest available PTX version that is supported by the currently loaded GPU driver. The driver has a specific error code it will return if you pass it PTX that is of a version it doesn’t recognize)
As I’m typing this, an alternate, kind of strange approach occurs to me. You could use NVRTC to convert a simple test case to PTX (
nvrtcGetPTX()), then use the generated PTX to inform yourself of the current PTX version that the driver understands.