cudawrappers on Windows

[loostrum]

For the ultrasound part of the RECRUIT project I'd like to see if we can use cudawrappers, but their production system runs windows. I see no reason why cudawrappers shouldn't work on windows, but I haven't tried it. @csbnw have you ever tried it?

I can set up a windows machine at home to test if needed, I should still have an NVIDIA GPU lying around somewhere.

[csbnw]

We (at ASTRON) have never tried compiling and running cudawrappers on Windows. It is an interesting use-case, but to properly "support" this, we would also need to include Windows in the CI pipeline.

[loostrum]

Supporting it in the CI seems difficult. For my use case I'd be more than happy to have it as an experimental, no-promises-that-it-works feature, but I can also understand if you don't want such a non-supported feature.

In any case I'll see if I can get it to build on my Windows machine at home.

[loostrum]

The current code doesn't work as-is on windows, I thought I'd share my findings here:

• When CUDAWRAPPERS_BUILD_TESTING is enabled a few coverage flags and debug are set, these don't work with msvc.
• The fancy target_embed_source macro uses ld to convert a source file directly into an object file. The windows linker can't do this, and there doesn't seem to be a windows tool that can. We could default to loading the source file at runtime on windows, leaving out this embedding entirely.
• There is an issue in the cu::DeviceMemory constructor, see this error:

C:\Users\Leon\source\repos\cudawrappers\tests\test_cufft.cpp(71): error C2668: 'cu::DeviceMemory::DeviceMemory': ambiguous call to overloaded function
C:\Users\Leon\source\repos\cudawrappers\include\cudawrappers/cu.hpp(458): note: could be 'cu::DeviceMemory::DeviceMemory(CUdeviceptr)'
C:\Users\Leon\source\repos\cudawrappers\include\cudawrappers/cu.hpp(438): note: or       'cu::DeviceMemory::DeviceMemory(size_t,CUmemorytype,unsigned int)'
C:\Users\Leon\source\repos\cudawrappers\tests\test_cufft.cpp(71): note: while trying to match the argument list '(const size_t)'

The constructors are marked as explicit, but for some reason it doesn't pick the one with a size_t argument, presumably because CUdeviceptr and size_t decay to the same type. I'm not sure why this happens.

The coverage and source embedding seem easy enough to fix, but I'm not sure what to do about the DeviceMemory constructor.

[csbnw]

The DeviceMemory constructor has the following signature:

explicit DeviceMemory(size_t size, CUmemorytype type = CU_MEMORYTYPE_DEVICE, unsigned int flags = 0)

How about removing the default value for the second parameter? It will however likely cause some existing code using this API to break.

[loostrum]

That does fix the issue, but is rather unfortunate. I quite like being able to do call cu::DeviceMemory(size) without having to specify the memory type. Calling DeviceMemory with a CUdeviceptr seems like the less used variant? If we could somehow change that one that might be better, although I'm not sure how we'd do that.