Open loostrum opened 7 months ago
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.
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.
The current code doesn't work as-is on windows, I thought I'd share my findings here:
CUDAWRAPPERS_BUILD_TESTING
is enabled a few coverage flags and debug are set, these don't work with msvc.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.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.
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.
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.
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.