I so badly want to ditch Windows on all my personal machines. Literally the only thing keeping me is gaming support. Steam on Linux has helped a lot, and I can play a lot of previous generation titles on my Mint laptop, but AMD driver support is still lacking. It can't improve fast enough!
As a Linux user and gamer I can totally relate to this.
In my own experience, the gaming problem is almost solved when you have Nvidia Hardware with proprietary drivers, but AND and Intel drivers are really behind in that space. Hopefully, with Vulkan gaining market shares, we shouldn't have driver problems in the future (but I don't expect this future to come soon, maybe 2 years or so).
Running a virtual machine with PCI-e passthrough using IOMMU virtualization (e.g. intel_iommu in linux) is a popular option in gaming while using the Intel integrated for the Linux desktop.
I recently saw someone get better benchmark (Futuremark) results with Win10 running in a VM on Linux than native Win10.
I haven't tried this personally yet, but I do intend to.
They have attempted to in the past, but all it takes is one extra switch on KVM to get around any restrictions for passthrough to Nvidia cards. I currently have that setup running myself and it works perfectly.
It was apparently a hassle in the past, but the bypasses are basically built in to the tools now. Nvidia is calling the blocking behavior a "bug", but the have no intention to act on it.
It is not a bug. The windows driver contains KVM signatures, aswell as signatures for Hyper V extensions, and if they are enabled the driver fails to run. However if you modify the signatures in KVM and in HyperV devices, everything works fine. This is clear cut NVIDIA malfesence.
That's why I put it in quotes. It's pretty clear the original intent was to push people to get Quattro cards for using in VMs. My impression is that they gave up on the idea for normal users and are trying to play it off while suggesting they aren't going to fuck with people any further.
This should be documented and spread more widely. Nvidia seems to use the same tactics as Intel in market segregation and also some semi-related bullying tactics.
It's not a stable solution, and there are two problems with this kind of things.
The first is that it's pure, unsubstantiated, guesswork. You'll spend countless hours changing obscure undocumented parameters hoping that things will work. I tried, and it's not a fun thing to do, because you don't learn anything substantial.
Second, this type of operations have a sky-high level of brag factor. People will tell on their blogs/posts that they succeeded in "making XXX work and that it's stable", but they don't tell you that their computer explodes (so to speak) two minutes after they start XXX. Again, I know because I've worked on similar things, and the patterns are the same.
You may be lucky, but if you aren't, it's a lot of time wasted (it always looks like the "final solution" is behind the corner!).
The guys from LinusTechTips have used Unraid (a paid KVM+BTRFS based NAS+VM appliance) to do this with a 7 or 8 GPU machine. See 7 gamers one PC on YouTube. It seemed to be simple to set up, once you have configured the BIOS.
Yeah, it can be a bit guessworky, but that's only because it's bleeding edge stuff. The corners are being sanded down and things are getting better rapidly. I've been happy with the amount of work that I've put into my setup versus the results. And my setup is definitely not one that causes my computer to explode. In fact, I've never had my host machine fail. The VM only bugged out once. This is after long sessions of CS:GO, Overwatch, Game of Thrones, StarCraft 2, etc.
I was pretty apprehensive about the concept, but hopeful enough to get a new mobo/CPU just to give it a shot. It does definitely seem to good to be true.
I went for it, and it actually ended being significantly easier and better performing than I expected. I did have to take a few days and learn a bit about qemu, but I'd expect that much.
I will say that older motherboard (perhaps some new ones too) might not have firmware that fully support what's being done here. It's hard to say which, but you can see what people have had success with if you search around (Asus z170a works for me).
I am in the exact same boat. My laptop is Xubuntu and my work computer is as well. My home gaming rig is Windows 10 because Linux just doesn't compete yet with the proprietary optimizations that the hardware manufacturers and game developers use on the platform. Also my wireless card doesn't have Linux support but I would throw that in the trash the moment Linux gaming can even get to 80-90% of the Windows gaming performance.
If this were Slashdot we couldn't even have the discussion without being swamped by fanboys claiming completely false things about Linux gaming. I've been trying over and over again for about 15 years playing all different types of games on different types of hardware and roughly speaking I would say an average of 20-50% performance hit on 3D rendered games but it is getting much MUCH better.
It does work but I didn't spend the, honestly, stupid amount of money on my home PC to have it perform worse than it can just based on the software I choose.
There's a billion reasons why this is the case so saying one specific thing or manufacturer is going to fix it but AMD pushing support is a wonderful thing. I can't wait until I can finally get rid of Windows completely.
Really what I would love is a gaming focused Linux distro that actually works.
ha! yea, I tried it early in development and it was a bit of a mess I should give it another shot that it's a little more mature. Their whole steambox/steamcontroller thing seems to have flopped but I'm sure it's better than it was on initial release.
I think that it was just ahead of its time, and people didn't really "get it", and it wasn't marketed with the right message or marketed enough. The next PlayStation and Xbox seem more like gaming PCs than consoles, and it looks like the market is trending toward a shared experience across all devices in the future.
I really hope that SteamOS continues and sees wide adoption, but I also agree from my experience mining btc on Linux years ago that drivers need to improve, as does the hack factor. As a sysadmin then, I struggled for hours to get the AMD + OpenCL stuff working right. Not sure if it's better now, but no way would the mainstream accept that type of experience to play games.
I'm hopeful it'll get better. Steam itself was _awful_ in the early days. There's an old NSFW animated gif of the Steam logo that's tells you a little bit about how early users felt when Steam became mandatory to play Counter Strike. Look at Steam today, though. It's gone through a tremendous evolution.
If your gaming rig exists to play games then why does it matter that it runs Windows? Your interaction is pretty much limited to "click on game icon" or "open Steam".
Or are you wishing that you wouldn't have to have a separate gaming rig if only games ran well on Linux? Then you could ditch the laptop and you wouldn't need 2 computers at home?
You should seriously look into running a VM with pcie passthrough if you've got a desktop.
There's a lot of talk about complexity and dead end edge cases, however, having now done it, I can honestly say it was significantly easier than I was expecting and absolutely stable and fast thus far. I can't speak to edge cases (conversely, I can vouch for the Asus z170-* motherboard line), but my impression was that there is less and less of them as motherboard BIOSs advance.
It seems to be an area where things are developing fast. You'll find a lot of out-of-date resources telling you things like, for example, most nvida cards will not work or require effort to get working. The reality now is that it just requires a single argument in qemu to bypass the nvidia issue.
In my opinion, it's a significantly better solution than dual booting and basically indistinguishable from normal Windows performance-wise for gaming.
Is there a way to dynamically reassign GPU between host/VM(s)?
Not everyone can afford several high-end GPUs, so it'd be really nice to use it on host OS up until the moment you run gaming VM, and then switch host to lower/embedded GPU.
This will be considered suboptimal by some, I'm sure, but the solution I went with is to reserve the dedicated GPU for the VM and use Intel integrated for Linux, in my case from a skylake i5-6600. Aside from that, you can get a cheap, low power second GPU (if you're using an AMD CPU for example). This is fine for me since I'm gaming on the VM, and not really doing much graphically intensive on Linux.
The idea of getting another high end card seems pretty absurd when you're putting windows in a VM specifically to deal with those situations. I recognize some people have special use cases, but they're just that, special use cases.
Really, overall, I don't consider it to be too bad of a trade off for what you get.
On a related note, I have a hard time understanding the layout of the Linux graphics stack as a whole. You have MESA, DRM, DAL, Gallium3D, etc... All these acronyms and systems that somehow relate to eachother.
It seems like there are many layers, and there aren't many good references that really explain it "from the beginning".
I think the basic way to understand it all is that the decision was made to pull more of the graphics stack into the Linux kernel, and this has enabled thinner abstractions to be built on top for various purposes. For example, Wayland makes use of the underlying DRI infrastructure.
I've been wondering how Wayland actually works underneath. Seeing how Wayland window managers usually have a drawing layer that among others have a specific backend for Intel, I scratched my head wondering if people have to reinvent/reimplement parts of what xf86-video-intel provides in Xorg. Any insight?
There are different ways to create GPU drivers for Linux. In order to make use of DRI, the GPU has to have a DRM driver. This DRM driver is specific to the GPU hardware.
The DRM is the interface that software can work with to make calls to the GPU. You could think of DRM as a way to have a standard interface for GPU calls, so other software will speak to this DRM layer, but the DRM driver will speak to the hardware, which is why the DRM driver needs to be device specific.
The DRM driver is the part of the GPU driver that sits in the kernel, there will also be a userland part of the GPU driver. I believe the part of the driver that gets used will depend on what the software is targetting. Wayland will target the kernel side, but games would work with the userland side.
As a side note, it's possible for GPU vendors to create more generic GPU drivers by using Gallium3D. This also creates drivers that work with DRI, but GPU drivers don't need to use Gallium3D to use DRI. I would suggest thinking of Gallium3D as a set of reusable GPU driver components, you could code a driver using these reusable components, or you could code something bespoke.
Yes, the picture kinda confirms my suspicion. Looking at this https://github.com/michaelforney/wld/blob/master/intel/i965_... you have to wonder how much device-specific stuff one has to implement now when targeting Wayland and if that's avoidable or why libwayland doesn't have libwayland-intel etc?
By the looks of that header file, the i965 driver covers multiple different devices, I'm guessing it's using those values to enumerate a list of the Intel CPUs that the driver works with.
In terms of Wayland, I would suspect that it isn't necessary to have anything vendor specific, the whole point of targeting an abstraction layer like the DRI is to eliminate the need to cater for differences in devices.
I doubt that. libdrm should have been enough, but this was about two years ago, when Wayland wasn't ready. I don't know much about how wld is using libdrm_intel, and I don't think I'll be much the wiser even if I read the code. Maybe ask the author.
Super hype for a zen+polaris GNU/linux machine. Not a big fan of nvidia anti consumer practices but AMD have always been rubbish on GNU/linux, hopefully this will change!
It seems like AMD is really trying to do well by the open source community. I do realize that this isn't out of the kindness of their heart, but rather the fact that they're the underdog, but still, it's good for the community.
I really think things are going to turn in their favor within the next 2 years (at least in the graphical side of things).
Every single one of the major game consoles are using AMD chips, and consoles are usually first priority for game developers. I am guessing this could have some advantages when it comes time to do a PC port.
Also, with the new APIs such as Vulkan and DX12, the amount of optimization "games" you can play inside the driver is reduced since they are apparently much closer to the hardware. This could wash away some of the lead that NVidia has (as is proven by many recent DX12 benchmarks).
Finally, I think the recent rise in popularity of Apple computers (last 5 years or so) could be a good thing for Linux gaming since they will both rely on the Vulkan/OpenGL APIs which could give more incentive for developers to do the port.
I actually started using AMD cards two years ago after I started having problems with the Intel drivers. The drivers were somewhat rough initially but lately they have been very solid.
I just got a new computer and had to wrestle with PCI-E/graphics issues for the whole week but I got them solved now and it wasn't actually the Radeon driver as I originally suspected but rather Intel again (as I understand it).
The Intel drivers have had many serious regressions in the last year, so they are not the pinnacle of quality anymore. Both the X driver and the kernel drm bits. One major regression set was introduced in 4.3 with the atomic modesetting changes. It's almost like Intel has cut funding for QA.
The new AMD drivers will have only user space binary parts and everything in the kernel will be open source and integrated upstream. This way, you can have the latest and best AMD driver code for Vulkan and OpenGL bits.
I want to use an AMD GPU but would like to have one that is comparable in energy requirements to Intel's GPU. I just don't want to have a GPU that uses 150 or 200 watts but the Intel drivers are regressing so much that AMD seems like a safer bet.
The APU chips all have GPUs that handily beat Intel's and still have TPD from CPU+GPU of 100w or less. My desktop is an A8 from 2013 and while no power house even while new it runs XCom and GRID just fine (though I am using the very up-to-date drivers from the oibaf ppa)
Yeah, but you need to use an AMD CPU. And their performance has not yet caught Intel. Hopefully the new Zen architecture will make them competitive again.
I compile a lot of code and also encode videos where an Intel i3 will beat the APU. That's the dilemma I'm in, and it's a pity that the Zen APUs don't arrive until 2017. First it's the CPU only Zen chips, but maybe the new AMD GPUs will allow for low-power variants.
How is the smoothness of the AMD drivers? Any tearing as it reliably happens with all Intel GPUs and latest kernels and X drivers if you don't force vsync?
The thing I'm most psyched for is the continuing evolution of OpenCL support. It seems like the AMDGPU+Gallium3d/etc stack has some support for OpenCL already. Image2d/3d support would be outstanding.
I've seen so much instability from catalyst+southern islands and I'm hoping the issues are driver related and Linus' Law will result in a higher quality computation stack.
57 comments
[ 91.3 ms ] story [ 1705 ms ] threadIn my own experience, the gaming problem is almost solved when you have Nvidia Hardware with proprietary drivers, but AND and Intel drivers are really behind in that space. Hopefully, with Vulkan gaining market shares, we shouldn't have driver problems in the future (but I don't expect this future to come soon, maybe 2 years or so).
I recently saw someone get better benchmark (Futuremark) results with Win10 running in a VM on Linux than native Win10.
I haven't tried this personally yet, but I do intend to.
It was apparently a hassle in the past, but the bypasses are basically built in to the tools now. Nvidia is calling the blocking behavior a "bug", but the have no intention to act on it.
The first is that it's pure, unsubstantiated, guesswork. You'll spend countless hours changing obscure undocumented parameters hoping that things will work. I tried, and it's not a fun thing to do, because you don't learn anything substantial.
Second, this type of operations have a sky-high level of brag factor. People will tell on their blogs/posts that they succeeded in "making XXX work and that it's stable", but they don't tell you that their computer explodes (so to speak) two minutes after they start XXX. Again, I know because I've worked on similar things, and the patterns are the same.
You may be lucky, but if you aren't, it's a lot of time wasted (it always looks like the "final solution" is behind the corner!).
I went for it, and it actually ended being significantly easier and better performing than I expected. I did have to take a few days and learn a bit about qemu, but I'd expect that much.
I will say that older motherboard (perhaps some new ones too) might not have firmware that fully support what's being done here. It's hard to say which, but you can see what people have had success with if you search around (Asus z170a works for me).
This is a little light on details but is a good resource for the steps involved: https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...
If this were Slashdot we couldn't even have the discussion without being swamped by fanboys claiming completely false things about Linux gaming. I've been trying over and over again for about 15 years playing all different types of games on different types of hardware and roughly speaking I would say an average of 20-50% performance hit on 3D rendered games but it is getting much MUCH better.
It does work but I didn't spend the, honestly, stupid amount of money on my home PC to have it perform worse than it can just based on the software I choose.
There's a billion reasons why this is the case so saying one specific thing or manufacturer is going to fix it but AMD pushing support is a wonderful thing. I can't wait until I can finally get rid of Windows completely.
Really what I would love is a gaming focused Linux distro that actually works.
I think SteamOS was supposed to be that distro, but at some point it just kind of... ran out of steam?
I really hope that SteamOS continues and sees wide adoption, but I also agree from my experience mining btc on Linux years ago that drivers need to improve, as does the hack factor. As a sysadmin then, I struggled for hours to get the AMD + OpenCL stuff working right. Not sure if it's better now, but no way would the mainstream accept that type of experience to play games.
Or are you wishing that you wouldn't have to have a separate gaming rig if only games ran well on Linux? Then you could ditch the laptop and you wouldn't need 2 computers at home?
There's a lot of talk about complexity and dead end edge cases, however, having now done it, I can honestly say it was significantly easier than I was expecting and absolutely stable and fast thus far. I can't speak to edge cases (conversely, I can vouch for the Asus z170-* motherboard line), but my impression was that there is less and less of them as motherboard BIOSs advance.
It seems to be an area where things are developing fast. You'll find a lot of out-of-date resources telling you things like, for example, most nvida cards will not work or require effort to get working. The reality now is that it just requires a single argument in qemu to bypass the nvidia issue.
In my opinion, it's a significantly better solution than dual booting and basically indistinguishable from normal Windows performance-wise for gaming.
Link you might want to check out: https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...
Not everyone can afford several high-end GPUs, so it'd be really nice to use it on host OS up until the moment you run gaming VM, and then switch host to lower/embedded GPU.
The idea of getting another high end card seems pretty absurd when you're putting windows in a VM specifically to deal with those situations. I recognize some people have special use cases, but they're just that, special use cases.
Really, overall, I don't consider it to be too bad of a trade off for what you get.
DRM is a really unfortunate acronym here. It took me a while to figure out it refers to direct rendering manager.
It seems like there are many layers, and there aren't many good references that really explain it "from the beginning".
http://blog.mecheye.net/2012/06/the-linux-graphics-stack/
The implementation-and-mailing-lists-are-documentation practice bites badly :)
https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructur...
I think the basic way to understand it all is that the decision was made to pull more of the graphics stack into the Linux kernel, and this has enabled thinner abstractions to be built on top for various purposes. For example, Wayland makes use of the underlying DRI infrastructure.
There are different ways to create GPU drivers for Linux. In order to make use of DRI, the GPU has to have a DRM driver. This DRM driver is specific to the GPU hardware.
The DRM is the interface that software can work with to make calls to the GPU. You could think of DRM as a way to have a standard interface for GPU calls, so other software will speak to this DRM layer, but the DRM driver will speak to the hardware, which is why the DRM driver needs to be device specific.
The DRM driver is the part of the GPU driver that sits in the kernel, there will also be a userland part of the GPU driver. I believe the part of the driver that gets used will depend on what the software is targetting. Wayland will target the kernel side, but games would work with the userland side.
These images from Wikipedia may help visualise what DRM is doing. Without DRM: https://en.wikipedia.org/wiki/Direct_Rendering_Manager#/medi...
With DRM: https://en.wikipedia.org/wiki/Direct_Rendering_Manager#/medi...
As a side note, it's possible for GPU vendors to create more generic GPU drivers by using Gallium3D. This also creates drivers that work with DRI, but GPU drivers don't need to use Gallium3D to use DRI. I would suggest thinking of Gallium3D as a set of reusable GPU driver components, you could code a driver using these reusable components, or you could code something bespoke.
https://en.wikipedia.org/wiki/Gallium3D
In terms of Wayland in particular, you may be interested in this:
https://wayland.freedesktop.org/architecture.html
Does this help?
In terms of Wayland, I would suspect that it isn't necessary to have anything vendor specific, the whole point of targeting an abstraction layer like the DRI is to eliminate the need to cater for differences in devices.
EGL is sort of a cross-platform spec for window managers to work with graphics cards.
It seems like AMD is really trying to do well by the open source community. I do realize that this isn't out of the kindness of their heart, but rather the fact that they're the underdog, but still, it's good for the community.
I really think things are going to turn in their favor within the next 2 years (at least in the graphical side of things).
Every single one of the major game consoles are using AMD chips, and consoles are usually first priority for game developers. I am guessing this could have some advantages when it comes time to do a PC port.
Also, with the new APIs such as Vulkan and DX12, the amount of optimization "games" you can play inside the driver is reduced since they are apparently much closer to the hardware. This could wash away some of the lead that NVidia has (as is proven by many recent DX12 benchmarks).
Finally, I think the recent rise in popularity of Apple computers (last 5 years or so) could be a good thing for Linux gaming since they will both rely on the Vulkan/OpenGL APIs which could give more incentive for developers to do the port.
Apple haven't included any real OpenGL updates in years, and have meanwhile released Metal, their own cross platform (OS X / iOS) abstraction layer.
Wouldn't get your hopes up expecting Vulkan support from Apple.
I just got a new computer and had to wrestle with PCI-E/graphics issues for the whole week but I got them solved now and it wasn't actually the Radeon driver as I originally suspected but rather Intel again (as I understand it).
I've seen so much instability from catalyst+southern islands and I'm hoping the issues are driver related and Linus' Law will result in a higher quality computation stack.
what could possibly go wrong ...