Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cuda support not working on WSL2 #1008

Closed
Juff-Ma opened this issue May 26, 2023 · 6 comments · Fixed by #1177
Closed

Cuda support not working on WSL2 #1008

Juff-Ma opened this issue May 26, 2023 · 6 comments · Fixed by #1177

Comments

@Juff-Ma
Copy link

Juff-Ma commented May 26, 2023

Hello, i tried testing an app with CUDA on WSL2, on Windows it worked perfectly fine but in WSL it doesn't detect a Cuda device but only the CPU accelerator. The nvidia deviceQuery sample and nvidia-smi detect my GPU fine and can run CUDA on it.

here is my test code:

using ILGPU;
using ILGPU.Runtime;

const float PI = (float)Math.PI;

using Context context = Context.Create(builder => builder.AllAccelerators());

Device device = context.Devices.First(x => x.AcceleratorType == AcceleratorType.Cuda);

using Accelerator accelerator = device.CreateAccelerator(context);

var deviceData = accelerator.Allocate1D(Enumerable
    .Repeat(0, 10)
    .Select(_ => Random.Shared.Next(0, 500))
    .ToArray());
var deviceOutput = accelerator.Allocate1D<float>(100_000);

var loadedKernel = accelerator.LoadAutoGroupedStreamKernel(
(Index1D i, ArrayView<int> data, ArrayView<float> output) =>
    output[i] = data[i % data.Length] * PI
);

loadedKernel((int)deviceOutput.Length, deviceData.View, deviceOutput.View);

accelerator.Synchronize();

foreach (float i in deviceOutput.GetAsArray1D())
{
    Console.WriteLine(i);
}
@Juff-Ma
Copy link
Author

Juff-Ma commented May 26, 2023

Addition, when using OpenCL in WSL2 (intel iGPU) it works completely fine

@MoFtZ
Copy link
Collaborator

MoFtZ commented May 27, 2023

welcome @Juff-Ma. I'm not sure anyone has previously tried ILGPU on WSL2, however, I'm surprised that the Nvidia sample projects work and ILGPU is not able to find the GPU.

ILGPU will attempt to find the Cuda drivers. On Linux, this should be libcuda.so. It could be that WSL2 puts the drivers in a different location. Or that ILGPU found the drivers, but for some other reason, determined that it was not compatible.

Will investigate when I have a chance.

@Yey007
Copy link
Contributor

Yey007 commented May 28, 2023

ILGPU will attempt to find the Cuda drivers. On Linux, this should be libcuda.so. It could be that WSL2 puts the drivers in a different location.

@MoFtZ I believe this is the case. In WSL libcuda.so seems to be under a special wsl directory (/usr/lib/wsl/lib). Would this prevent ILGPU from finding the driver? Do we need to make ILGPU search this path as well?

Edit: I can verify that the CUDA accelerator is not found on my WSL install either.

@Juff-Ma
Copy link
Author

Juff-Ma commented May 28, 2023

Yes,not only the cuda library is under /usr/lib/wsl/lib but CUDA itself is not in path (the installer didn't put /usr/local/cuda/bin in path and /usr/local/cuda/lib64 in the linker path)

@Yey007
Copy link
Contributor

Yey007 commented Jun 6, 2023

Sorry for the long wait but I think I'll try to take a look at fixing this today.

@Yey007
Copy link
Contributor

Yey007 commented Jun 7, 2023

Upon further research, this seems to be an issue with WSL rather than with ILGPU. I don't exactly understand what causes it, but the dynamic linker just cannot find libcuda.so on WSL for some reason, though libcuda.so.1 works fine.

I think we have two options at this point:

  1. Wait for Microsoft to resolve the issue and, in the meantime, use this pretty simple workaround.
  2. Search for libcuda.so.1 instead of libcuda.so when trying to load the library. This is as simple as changing a string, and I have implemented it here. I'm not sure if this works on regular Linux so testing would be appreciated, but it works fine on WSL. I'll hopefully get to testing on regular Linux soon as well.

Any thoughts on which approach we should move forward with?

@MoFtZ MoFtZ added this to the v2.0 milestone Apr 10, 2024
@MoFtZ MoFtZ modified the milestones: v2.0, v1.5.2 Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants