Ask Slashdot: Can Linux Run a GPU-Computing Application Written For Windows?
dryriver writes:
I have been told that Linux can run Windows software using Wine or perhaps a VM. What happens if that Windows software is a GPU-computing application -- accessing the GPU through HLSL/GLSL/CUDA/OpenCL or similar interfaces?
Can Wine or other solutions run that software at a decent speed under Linux? Or is GPU-computing software written for the Windows platform unsuitable for use -- emulated or otherwise -- under Linux?
This sounds like one of those cases where there's a theoretical answer and then your own real-world experiences. So leave your best answers in the comments. Can Linux run a GPU-computing application that's written for Windows?
now go away
Maybe.
Just cruising through this digital world at 33 1/3 rpm...
PCI express passthrough is the term to search for.
A good writeup:
https://www.reddit.com/r/pcmasterrace/comments/2z0evz/gpu_passthrough_or_how_to_play_any_game_at_near/
It used to be there was no Linux Folding@Home application. But there was a way to run the Windows CUDA application on Linux, and I did for a couple of years.
Here's a guide for that: http://www.overclockers.com/de...
(T>t && O(n)--) == sqrt(666)
Even if it runs under something like WINE, how fast does it run?
I would assume that if you need something that uses CUDA, performance is important.
The real "Libtards" are the Libertarians!
Lots of Linux and crossplatform applications have been using GPU regardless of the OS for a while now. Blender is a good example. Sometimes all it takes is the right drivers. Please tell me you're not trying to run Maya or something like that when you got Blender? :(
Run Windows. I never have used wine. Linus himself said if you need to run win32 then run host OS. Linus used XP for PowerPoint.
How would you feel if I asked you if I could run Ubuntu on Windows 10? I could but why? It's a geek toy. At work your job is to put ideology aside and to make your bosses happy by keeping it up.
Will running Windows Server really be that horrible for 1 server?
But if I did have to run Linux I could try KMS with GPU pass thru but you risk downsides on now 2 platforms and bugs for now KMs, Linux, and windows and a performance hit. That won't guarantee higher uptime.
http://saveie6.com/
Why not just google "wine + CUDA" or "wine + openCL" and read the doco?
Google indicates that wine has CUDA and OpenCL support so.
In any case, quite a bit of GPGPU stuff is written cross platform so you just need to re-compile for your platform.
If it is GPU bound, then wine is perfectly fast enough for acting as a 'windows i/o emulation layer' to pump the data to the cards (barring any serious regressions, wine is at worse usually 2-3x as slow as windows, due to the extra API overhead. But in some cases is faster due to filesystem, memory or i/o subsystem, etc.) In that case, so long as the wine API can pass through all the GPU programs needed and pull the results back to the windows apps, it should work exactly the same as on Windows, but with the benefit of a few hundred to few thousand dollars worth of licensing that can be put towards GPUs instead (assuming of course the apps in question are not proprietary or have DRM which restricts them to running on authentic windows systems only. In that case, you might instead consider a VM+IOMMU platform using either xen or qemu/kvm with PCIe passthrough to run a real copy of windows and your GPU app, subject to licensing restrictions.)
Few things:
1) Why not just google "wine + opencl" or "wine + CUDA"? Google indicates support has been around for a few years.
2) Why not test it?
3) Most GPGPU applications are written cross platform and therefore just have to be recompiled for their target platform with no/minimal changes.
4) HLSL/GLSL isn't really used for GPGPU computing these days.
Just like I wouldn't go the other way and do a Linux computation program on Windows. Thing is if you are talking about something that needs the GPU for acceleration, you are talking about something doing some heavy hitting math. The reason you bother with a GPU is because whatever you are doing is too slow just running on a CPU. Otherwise why bother? It is more work and restricts systems that can run it.
Well any emulation/virtualization/whatever will slow things down. How much varies, but even in the best case scenario, there's a performance penalty. Why pay that? Just run it in the OS it wants to run in on the iron. That'll get you the best performance.
Not only that but generally speaking technical and engineering software is not the best written, most stable stuff in the world. You are likely to find it quirky even when you run it in the environment it wants. Introducing more variables is just going to make problems more likely and your life more difficult.
Which, of the thousand of versions are you babbling on about, son! Unless you like betting on long shots, the answer is NO! Now get back to the basement. We'll tell you when to come out!
1. You are using the latest Linux kernel with gcs-bgg patches.
2. You have matching sticks of ECC RAM.
3. Muslim terrorists have not blown up your computer.
Best thing is to simply try it. Doom 3 works with Vulkan. You may also see into commercial products based on Wine. Such exist. I heard a few apps work with OpenCL. Best thing would be to try. I assume it's not server cluster we are talking about.
should you?
Just build a new Z-80 SoftCard https://en.wikipedia.org/wiki/...
Domestic spying is now "Benign Information Gathering"
Is Windows better than Linux. I personally don't care and don't harbour a grudge if you use either. Windows offers easy installs and has a wider ( ? ) choice. Windows users just want their application or program to work on their computer instantly.. Linux (outside of Web searches, LibreOffice, and Emails, requires work and sometimes sweat if you are trying to make something work that doesn't. Why am I saying all this? (No! I don't want you to change your Operating System!) But.. If Windows decides to do something that makes you want to look elsewhere. Are you prepared to jump to a different ship if need be? Plus maybe to them, the threat of you jumping ship might keep them in line!
Read the QEMU documentation on PCI-E passthrough.
VMware ESXi 6.5 + HorizonView 7 + (the right card - i.e. Nvidia GRID) is a supported configuration to take advantage of a GPU-intensive application.
GPU computing professional here.
What application are you running that you don't have the source for and needs specifically windows?
I've only seen windows used for compute in a few isolated cases, and the people using it wouldn't be trying to run it on Linux cause they wouldn't know how.
I'd say best bet would be to run a VM with Windows in it and give it access to the hardware you need.
> Just run it in the OS it wants to run in on the iron.
Sometimes that certainly makes sense. Sometimes that would be really inconvenient and provide no benefit at all.
> Well any emulation/virtualization/whatever will slow things down. How much varies, but even in the best case scenario, there's a performance penalty.
That's not true. There is no measurable performance penalty for any application that's waiting on hardware such as the GPU or waiting on an external resource, typically over the network. As a stupid simple example, consider curl. Downloading a 100MB file over a 10Mbps connection will take 100 seconds, whether you're running on bare metal or three levels of virtualization deep.
If the CPU is sitting around waiting for the GPU to process the data, it doesn't matter if the CPU waits 10% "slower". A GPU-bound application will run just as fast whether the CPU is virtualized with PCI passthrough or not - it's not waiting on the CPU anyway.
Performance is all about the bottleneck. If the application is slowed because it's waiting on the CPU, it doesn't matter how fast the disk is. If the application spends it's time waiting on the network, it doesn't matter how fast the CPU is, etc. The only component that matters for performance is the component that's at ~100% utilization. (Ignoring for a moment trading disk and RAM via caching and paging).
There are cross platform libraries that work equally well on Linux and Windows.
You need to plan for it in advance.
Its probably easier than you think if you have the source code.
Will running Windows Server really be that horrible for 1 server?
It may, it really depends. If you are running a system that must be compliant (PCI, NISPOM/JFAN, FedRAMP, etc..) it absolutely may be horrible. You not only need that 1 Windows server, but all of the supporting infrastructure to make it compliant. That 1 server is now 2 or 3, and you need manpower and time to go with it.
So if you can run Windows, I agree with GP. Where I work, the vendor would either port or we wouldn't run it.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Besides pass through, you might be able use the new virtual GPU features as they mature:
https://linux.slashdot.org/story/17/02/20/0014202/linux-kernel-410-officially-released-with-virtual-gpu-support
My recent appempt to run the Windows software for High Fidelity in a Virtual Box on a linux machine with a good Nvidia card met with frustration when I chould not get the program to see the card from within the box.
My attempts to run the windows software for High Fidelity in a virtual box on a linux machine with a good Nvidia card were frustrated because the program could not use the video card.
You are absolutely right that you can do this but you may need to patch the hypervisor if you use a standard, retail nVidia card. Nvidia's drivers for "gamer" GPUs check to see whether they are running in a virtual environment and then shutdown if they think they are. There is a patch for KVM which hides the virtual environment from the nVidia driver so that it will run.
Alternatively if you need double precision or don't mind spending 5-10 times the cost of a gamer card you can purchase a Tesla GPU since the nVidia driver for these works fine in a VM without patching.
I've been very frustrated trying to get my Optimus based GeForce 860M to work. The worst part of it is there isn't any real option to turn off the i7's Integrated Graphics problem from even an unlocked BIOS. So fuck it.
If you are going to go to the trouble of installing Windows VM under Linux and then piss around with settings and configurations to get your gpu application to run at a decent speed, why not just natively run Windows?
Not sure how things are in the prezent, but some time ago the problem/question was put by documents in DWG (a DOC or XLS of engineering field) inherited from Autocad.
Many companies already have made many projects in DWG files, exporting in another format can become problematic because of many reasons.
Using a common proprietary file format like DWG in day to day work, will impose, as a consequence, usage of a proprietary software product, many times not available on anything other than Windows. And not portable.
Hence the need for access API to GPU through HLSL/GLSL/CUDA/OpenCL of native host as real world requierment.
Actually some CAD platforms can run pretty well in WINE. Or CrossOver Office for practical reasons and less headache. Also support for CUDA, OpenCL it depends on the drivers or hardware support. Open source or proprietary.
I have used a opencl app via wine on linux. It was written in Java. Although supposed to be platform independent, they somehow messed up and it would crash under linux. I haven't made time yet to fix it, so I just used in under wine.
The performance was more or less on par with windows.
OpenCL is supported out of the box - check out the "wine-opencl" package:
https://fedora.pkgs.org/25/fedora-x86_64/wine-opencl-1.9.21-1.fc25.x86_64.rpm.html
Could you build a docker container based on Windows and run it in linux?
I've always said English was my second language. Had Romeo and Juliet been written in C, I might have understood it.
Compiled CUDA code (.cubin) is platform agnostic. You can use a cubin compiled on linux and it will work fine on windows (assuming compatible GPU).
I'm not 100% sure, but I believe that it would run using docker. Docker I believe uses the same base engine that VirtualBox uses, although from my limited use of this great tool, it runs significantly faster with less drain on resources. I don't believe that it would have any problems with accessing the GPU - at least no more than any other virtualization system, so would be a viable option to consider.
Linux can barely run a GPU at all.