Open Snafuh opened 1 year ago
Hi @Snafuh, so the issue is not that the GPU isn't exposed correctly to the container, but rather that WSL2 doesn't fully support the Vulkan graphics API yet. The way that WSL2 GPU access works is by making use of WDDM GPU Paravirtualization (GPU-PV), which exposes the DirectX kernel interface and accompanying DirectX 12 graphics + compute APIs to the Linux virtual machine. Other APIs then need to be supported by providing translation layers that convert API calls to their DirectX counterparts. At the moment, translation layers are provided for OpenCL and OpenGL and for NVIDIA CUDA (the latter of which communicates with the DirectX kernel interface directly rather than attempting to translate CUDA API calls to DirectX 12 compute API calls).
Microsoft is working on a Vulkan-to-DirectX translation layer called dzn
("Dozen"), which recently reached the milestone of supporting Vulkan 1.0. It looks like Microsoft is now working on Vulkan 1.1 support, so hopefully they'll continue until Dozen supports Vulkan 1.3, which is what I believe is required in order to run Unreal Engine 5.1. (Looking back through the release notes, it looks like Vulkan 1.2 support should be sufficient to run Unreal Engine 4.26, 4.27 and 5.0. For engine releases older than that, you can just use OpenGL instead.)
In the meantime, there are two options available:
If you're targeting Unreal Engine 4.25 or older then you can use the OpenGL graphics API by specifying the -opengl4
command-line flag. Unfortunately, OpenGL support was removed in Unreal Engine 4.26, so this option will not work for newer versions of the Unreal Engine.
If you're targeting Unreal Engine 4.26 or newer then you will need to run your GPU accelerated Linux containers on a Linux host system. This could be a bare metal installation (e.g. on another machine or dual-booting with Windows on your current machine), a GPU-enabled virtual machine instance running in the cloud, or a Linux virtual machine that has access to a physical GPU by means of PCI passthrough.
(Note that PCI passthrough will require either a Linux host system with IOMMU support and a hypervisor such as KVM, or a Windows Server host system with both IOMMU and SR-IOV support and the Hyper-V hypervisor. Client versions of Windows such as Windows 10 or Windows 11 do not support Hyper-V Discrete Device Assignment (DDA), and most consumer GPUs do not support SR-IOV, so a Linux host system is typically the most practical option for most developers, at which point you can just run the container directly on the host without needing a VM.)
I'm going to pin this issue for the time being, since this is a fairly common question that I hear from members of the community and improved visibility of the answer may help save some folks from wasting time trying to get UE working in WSL. I'll post updates here as Microsoft continues to improve Dozen, and I'll close the issue once the latest releases of the Unreal Engine are able to run under WSL2.
Update: Dozen now supports Vulkan 1.1. That was pretty quick, we'll see how long Vulkan 1.2 takes!
And now Vulkan 1.2 support has been implemented as well. Looks like Microsoft is pushing hard on this!
Wow, thanks a lot for that very detailed answer. I was doing further research after posting this issue and reached the conclusion about WSL2 not supporting this as well. Good to see Microsoft further pushing WSL2 capabilities.
Running the container on a Linux Host seems like the most stable and easy way forward. Building on Windows worked perfectly fine though. So containers can still offer great value for us Windows developers.
@Snafuh Hello! Did you manage to launch UE via wsl?
Hi
First of all, thanks a lot for supporting this project Adam.
I'm having issues getting an example project running. My GPU is not detected correctly and therefore the SDL Initialization fails
I'm running under a Windows host (my local dev setup). I'm able to correctly run the NVIDIA benchmark demo containers, so I think my host docker and driver setup is correct.
nvidia-smi displays my GPU correctly.
Some more cuda diagnostics in the same docker container
It seems like torch can find the GPU correctly as well.
My docker file:
Any ideas what kind of further diagnostics I could run despite nvidia-smi to see if the GPU is correctly exposed in the container?
Cheers, Kim