[UR][CUDA] Fix compatibility with CUDA 11.x

[al42and]

The code introduced in 74f42f8 uses the signature of cuGraphInstantiate from CUDA 12.x. In CUDA 11.4-11.8, the same function is called cuGraphInstantiateWithFlags, so we use it. In older CUDA, there is only the old version of cuGraphInstantiate which does not accept flags.

• https://docs.nvidia.com/cuda/archive/11.8.0/cuda-driver-api/group__CUDA__GRAPH.html#group__CUDA__GRAPH_1g433ae118a751c9f2087f53d7add7bc2c
• https://docs.nvidia.com/cuda/archive/12.0.0/cuda-driver-api/group__CUDA__GRAPH.html#group__CUDA__GRAPH_1g433ae118a751c9f2087f53d7add7bc2c

[al42and]

PR for pre-merge testing: intel/llvm#11773

[Bensuo]

Thanks for catching this! Changes look good to me just one minor comment.

[abagusetty]

Can we get this merged.

Fixes: #1119

[kbenzie]

Can we get this merged.

Fixes: #1119

About to do so.

PR for pre-merge testing: intel/llvm#11773

I'm going to close this testing PR. I'll replace it with a new intel/llvm PR that combines a number of UR PR's together with the goal of getting patches merged more quickly.

[al42and]

I'm going to close this testing PR. I'll replace it with a new intel/llvm PR that combines a number of UR PR's together with the goal of getting patches merged more quickly.

Sure thing!

By the way, is the whole "draft MRs in a different repo just to test" shtick a temporary solution, or is it intended to be the long-term way of running the project? I see the benefit when the changes to IntelLLVM and UR are tightly coupled, but, with two separate repos, I got the impression that the general direction was towards untangling them and making the development more independent?

[kbenzie]

By the way, is the whole "draft MRs in a different repo just to test" shtick a temporary solution, or is it intended to be the long-term way of running the project? I see the benefit when the changes to IntelLLVM and UR are tightly coupled, but, with two separate repos, I got the impression that the general direction was towards untangling them and making the development more independent?

I agree this is an unusual setup and it's primarily due to historical reasons. UR was born out of the Plugin Interface (PI) in intel/llvm which we are still in the process of fully migrating in the SYCL runtime.

We are still working towards decoupling UR from intel/llvm further but it's a time consuming process and must be balanced with our other commitments. The main area which needs improved is our level of testing, both API coverage and the OS/hardware support matrix.

Having now completed the move of all the adapter implementations to this repo the maintenance workload has increased quite a bit for me personally as a result of the current process. So I am personally invested in streamlining things for everyone involved in the project.

[al42and]

Thanks for the explanation, @kbenzie