Cuda 13

[tomsmeding]

This PR adds basic support for CUDA 13. As before, no new functionality was added; all I did was make the existing functionality work as well as possible with the new APIs. A few CUDA functions have gained additional parameters; these are not exposed in Haskell and simply filled with whatever makes the functions do what they previously did.

The most controversial part of this PR is that a few fields have been removed from cudaDeviceProp; here follows.

Device properties

The current design in these Haskell bindings is to have a single DeviceProperties data type shared between the driver API and the runtime API, and this data type is bound (via a dubious Storable instance that defines only peek, not poke, as not all C fields are reflected in Haskell) to what is available in cudaDeviceProp — a data type in the runtime API. This makes the implementation of the runtime API natural; the driver API is then written by querying all the necessary values using cuDeviceGetAttribute.

What is awkward about this design is that cudaDeviceProp does not contain all interesting properties about a device, so if a user is using the driver API, this DeviceProperties record is nothing more than a strange subset of all actual device properties: many that you likely won't need, and skipping some that you do need. This situation is exacerbated when NVIDIA decides that a bunch of fields are now (cuda 13) removed from cudaDeviceProps, meaning that if the current Haskell bindings design is retained, these fields also disappear from DeviceProperties, and users who were using them now have to manually query device attributes to get them.

This PR opts to keep the design the same and do the above, hence breaking clients. (I don't think there's a solution to this situation that incurs no breakage at all.) For accelerate-llvm-ptx, it turns out that only 1 dropped property was actually used (clockRate); the resulting patch, which compiles and tests successfully with this PR, is tomsmeding/accelerate-llvm@5eb8838.

@tmcdonell What do you think?

[tomsmeding]

I've rebased this PR on new master (though there were no conflicts), and I've squashed the first two commits together, because it turns out I was confused and the second commit just fixed a mistake in the first one, and it made no sense to keep them separate. The final diff of this PR has remained unchanged.

[tmcdonell]

Sounds like a great time to rip out all the runtime bindings into a separate package 🙃 (that may or may not ever come to fruition)

What's the timeline/impetus for cuda-13 support?

[tomsmeding]

Impetus for cuda 13 support is that cuda 13 is out, and cuda-toolkit from the nvidia repos for Ubuntu 24.04 has switched to cuda 13. This means that if one has an Ubuntu machine on the latest LTS and has cuda installed without explicitly specifying a particular version (hence getting the latest), then since August, apt upgrade breaks Accelerate.

The other impetus is that cuda-12 support on Hackage finally arrived approximately one week after cuda 13 was released. I hoped to be a bit earlier this time. :)

Taking out the runtime bindings is fine by me; I only use cuda through Accelerate, and Accelerate doesn't use the cuda runtime bindings. I don't even know if we have other users than Accelerate (do you?). However, even if we do that, there is still the question of what the size of the DeviceProperties data type should be, as there ceases to be even the struct from the runtime API to use for reference.

[tomsmeding]

@tmcdonell Would you be opposed to merging this as-is? I'd rather not wait longer, and it doesn't seem either of us is going to have much time/energy to spend on this. CI is very unhappy on this PR, but #84 builds directly on this one (and does not modify any of the files this modifies) and does have a happy Linux CI. (Windows is still broken and I'll leave that to you to fix if you want to.)

[tomsmeding]

On reflection, I'd also be happy with the decision to delete the Runtime bindings from this package; we can keep them in the git repo, but as a separate unreleased package.

[tomsmeding]

@tmcdonell This is how splitting the runtime modules into a separate package could look: compare view
I've made those changes on top of the #84 because #84 changes Setup.hs, and splitting out the runtime involved mostly copying Setup.hs (to make the CUDA paths available also to cuda-runtime). This double functionality is not nice, but it's good enough if we don't want to release cuda-runtime for now.