BETA: This article will be updated several times over the next few weeks so keep an eye on this space. Have some wisdom to add to the community knowledge pool? Do so in the comments at forum.level1techs.com !
So Steam updated and a big thing for people using Wine just popped up: Windows XP support for Steam will end in 159 days… This is the only way Chrome Embedded Framework works in Wine, because no one has worked on trying to get CEF working in Windows 7 mode. BattleNet already has expired WinXP support, and the result is the CEF just crashes each time, and nobody has bothered to fix it, cause it’s just reminders for Overwatch League. The best case scenario is that in the rare occasion CEF only loads images and not animated H264 video loops, it won’t crash with --no-cef-sandbox active as a command argument.
Steam is different. You can’t trade without CEF. You can’t watch video on Steam without CEF, you CAN’T BROWSE THE STEAM STORE WITHOUT CEF. And more recently, the Friends List won’t even work without CEF.
This is a pretty big deal so I’m hoping @wendell will make a point of that in the Wine part of the Gaming On Linux series of videos… cause otherwise no one will do anything.
So in talking with others, Arch has the patch for Steamwebhelper.exe, but it was considered an insignificant patch to be upstreamed since it’s just adding a command argument --no-sandbox, but this doesn’t fix the CEF issue with playing H264 content.
Others have been saying this patch has licensing issues, and can only be manually built into Wine, and cannot be released.
If there is actually a licensing issue, and if Wine upstream refuses to patch this, we’re at a standstill. VERY BAD for Wine gaming.
I personally think that Wine and Virtualization are damaging to the Linux gaming community. Mainly because of statistics. Those devs just see you as another Windows player and that might make them think that demand for Linux is below what it actually is. I know Linux demand is relatively small but this only shrinks it more. It’s why I personally have very little interest in those technologies despite how cool they are. Wine is a really amazing piece of software but in my opinion it’s a little too good. I suppose if someone would only play games either on Wine or on Windows I’d much rather they use Wine but I still would really like to see the Linux gaming community as a whole focus more on getting devs to do native ports.
I personally haven’t had any issues with the Fury on older kernels and I’ve been using AMDGPU basically since it started even being remotely viable(kernel 4.7 or something if I remember right). That being said I always run the latest(stable) kernel I can get my hands on anyway.
I will say this is 100% true for Subnautica. The PC version has the ability to render OpenGL, but it introduces graphical glitches that aren’t present if you use DirectX.
The Dev’s official response on a Linux version is “It works fine in Wine, there’s no need for a native Linux port.”
Then again, remember that under terms of releasing on Xbox as a console launch exclusive, they may be prevented under contract from creating a native Linux port. Mac is fine, but Linux is not. This is how MS can effectively control devs who wish to publish on Xbox One and PC at the same time.
We’re waiting for that big GPP reveal for Microsoft’s console game contracts, but the trend is if a Unity game is released on both Xbox and PC, it’s only available otherwise on Mac.
And soon the Mac landscape will change with Mojave forcing many devs that are making a Mac port to adapt for Metal native or MoltenVK. (Which I’m ALL FOR MoltenVK)
Well, that might be a point, but another bigger issue is that doing a native Linux port adds a big amount of costs for (let’s be honest) very little return.
The problem is that doing a native port takes people that know the system, not a lot of game devs do. So they would have to hire people specifically for that, and those people usually want some good money.
While porting is usually not a big deal for games that use UE or unity (because it’s a compile option) it’s not really feasible for studios that write their own engine or even modify either of the two.
And not every Dev can or wants to outsource the port to another company like feral interactive.
I think the big change will only arrive once studios start picking up either of the new APIs (DX12 or Vulkan), because if implemented properly they basically need to rewrite their whole rendering pipeline, and at that point they might as well use Vulkan instead of DX12 (because it doesn’t have any “big” advantages), I think when the star citizen people talked about that (tho I’m not a fan of that project, bit that’s not the point). And doing a Vulkan port is obviously a way easier task then porting a current game.
Star citizen is planning on moving fully to vulkan and eventually dropping DX altogether which makes me extremely happy especially since they’re also “planning” a Linux port. Although I wouldn’t hold my breath on that one. I agree with you though. I hope that the big devs move to Vulkan instead of DX12. What I don’t want is for wine to sort of become the defacto way of gaming on Linux. At that point you’re just playing games on FOSS Windows(on Linux). That is a terrifying future in my book. At that point the software might be FOSS but MS still has the control. They might not be involved with the project but the entire point of the project is to be compatible. That means MS APIs it means MS everything. The bright side is the code can be trusted…the down side is MS still wins(IMO).
Yeah I’m not sure what Apple was thinking. I personally don’t really care about the Mac ecosystem but I’m just looking at the decision and I just don’t get it. So much software uses OpenGL and while the big software will move to Metal without any problems smaller devs are basically going to give up(if they don’t use a big engine). Even some of the bigger devs I can’t imagine would be bothered to port. Look at Minecraft. Do we really think Minecraft will be ported to metal…probably not.
Hopefully, either way, if it’s ported entirely to Vulkan I could easily see wine working well with it.
I wouldn’t hold my breath on Star Citizen release at all because then I’d be dead for 2 years already.
But anyway, that’s what I meant. They said they basically have to rewrite half the engine if they want a “true” Vulkan build (not like the DX12 abominations that are going around).
On a sidenote: Doesn’t SC use CryEngine? They’d have to rewrite the whole thing for Vulkan… Or does it support Vulkan now? I haven’t followed it. I always thought it was DX exclusive.
/edit
CryEngine V apparently supports Vulkan. To what extent is another question.
Well, but that’s exactly his point. If the game is using DX then using wine is one thing, but if you’re going the Vulkan route there really isn’t much reason to not just build a native port, because the API is the same.
And as much as I like id software for showing people that Vulkan is a viable option, I don’t understand why Doom and Wolfenstein are not native Linux. As soon as people got it running on Wine (which… basically day 1) they basically said “oh well, it’s running already so why bother”.
In those types of scenarios I totally get @Scoopta’s concern. DX games are a different story though.
I totally agree with his concern, but if you want people to switch over to Linux (LIke I did) these technologies need to be there.
Maybe no Vulkan ports, that’s not excusable, but the idea of not using wine for other games is Ludacris.
The reason Linux has such a small gaming audience isn’t that people don’t like Linux. Tons of people understand Linux is much better than say, windows. It’s just there isn’t enough support/applications.
I’d rather the gaming demographic on Linux get smaller, and the overall market of Linux users increasing, which in turn would make developers more likely to port games to Linux, slowly increasing the gaming demographic, until overtime (hopefully) it snowballs and Linux has more than 1% of gaming share.
Fun fact, some engineers at id software made a Linux build of doom. Why it was never released…who knows. See: https://www.gamingonlinux.com/articles/doom-2016-could-have-been-on-linux-id-software-made-a-linux-version-sound-easy-to-do.11465/ Also they don’t use CryEngine V. They used to but if I remember right they moved to Amazon Lumberyard(a fork of CE V). How close that fork is to the real thing is another matter and I have no idea what the Vulkan support is like on Lumberyard.
AFAIK they only used that for the singleplayer thing, hence the lawsuit.
But not that it actually matters. We’ll probably not live long enough to see it released.
Yeah. I hope they’ll make a Linux version but they have to release the game first.
War Thunder has been talking about Vulkan for a while and only recently has it been revealed a hidden Alpha build Vulkan renderer is available for testing with War Thunder on Windows and Linux (MoltenVK for Mac hasn’t been coded yet, and Mac already has Metal)
I read that post, actually kinda cool. But it’s still a lot of work for them 
What kind of gpu would you need to run Linux with looking glass? Can it be crap single slot??
Yes. The only thing the Host GPU needs is a monitor output.
I have an idea about making VFIO easier for everybody. Given the fact that audio is the biggest problem right now for anyone doing GPU passthrough I was wondering if someone could help in this regard.
There have been attempts to solve this at GSoC:
https://wiki.qemu.org/Google_Summer_of_Code_2015#QEMU_audio_backend
https://wiki.qemu.org/Google_Summer_of_Code_2017#QEMU_audio_backend
by pumping audio through GStreamer but as far as I can tell no one took the project.
There is also a QEMU patch for solving most of these issues:
but it never got upstreamed and compiling it for anything other than Arch is more than you can ask from the average Linux user trying to get VFIO working.
To @wendell: Could you sprinkle a little magic like you did with LookingGlass this way? I think it will help the VFIO community more than anything else right now.