Google finally advances Linux+Vulkan gaming using a side door that bypasses the market share blocker altogether. MS and Sony don't like it and plan to mirror Google. Instead, they should stop being lock-in jerks, and should support Vulkan as well.
AMD is the big winner here, being behind the MS and Sony consoles for the last (and likely future) console generations and the Google Stadia service.
And with their GPU's going into datacenters and a move away from CUDA lock-in to OpenCL (example: https://www.openwall.com/lists/announce/2019/05/14/1 ), they're in a great position to increase market share of GPU accelerated tasks like AI and deep learning.
I'm a huge fan of the fact that Google is embracing a Linux + Vulkan stack for gaming, but I also want them to have meaningful competition. Yes it would be a dream scenario if MS & Sony started supporting Vulkan, but it would also be a nightmare scenario if Stadia started dominating the gaming market, and gaming technology stagnated for a decade at Vega56-class GPU's because there is no competitive pressure to push the envelope.
Sure, competition is good. But it doesn't mean it should come with lock-in problems. MS learned not to mess things up on the Web (remember ActiveX and Silverlight?). But when it comes to gaming, they are still as nasty as in the '90s. And Sony is even worse in this regard.
I agree about Stadia in general. I wouldn't want it to become too dominant, especially since it's like DRM on steroids - you can't back up anything from there. In general, I don't think regular gaming stores that sell rather than rent games are going anywhere. I.e. GOG, Steam and others are going to stay around. As long as Stadia won't be pushing exclusives, things will be good, since some will always prefer to run games locally.
You hit on my biggest concern, the fact that Stadia is DRM on steroids. Relative further reading for anybody that has questions on DRM and it's effects[1][2].
I think a lot of people are going to prefer to run games locally. I'm looking forward to playing strategy games on Stadia or games where lag isn't too critical. For quick reflex games, lag is important. And if VR games ever take off, lag is going to be critical.
Nobody cares what people think they want. In 5 years you'll be able to play AAA games on a $500 pc, pay by minute, and it'll be the only way to play them, and people will. Grudgingly, maybe, but they will. Everything on the server ('cloud gaming') is the only air tight DRM method, and publishers will jump on it as soon as it becomes viable at scale.
VR is the streaming killer. I was not entirely sure they'd even be able to get 2D video streaming like they have, because that already pretty much tapped out the technical prowess we can have. Heck, just running it over a network at all means you're going to experience pauses long enough to drop frames.
Since I assume Sony & Microsoft know this, and they aren't countering with a VR push but instead trying to match them with streaming, I suspect they judge the market either isn't there yet, or may never be there (on any business-realistic time scale). Or they just can't resist the DRM and lockin.
In the long term, streamed games (Stadia or similar) are definitely going to become dominant. Steam, et al, can still be storefronts, if they position themselves as such – we still need content curation.
All one needs is a screen with support (e.g. smartTV, chromecast, steam box), internet, and controllers. Classic game systems might be needed for another 5-10 years. Controllers & form factors matter (e.g. Switch, VR), but the "power" of PCs & game systems are no longer differentiators.
I suppose if Google starts kicking their butts in cloud gaming, they might loosen their stances on lock-in technologies in an effort to attract developers.
That's what I hope for. MS stopped being lock-in jerks on the Web only when they practically lost the browser wars. They need a stronger kick in gaming too, to start using cross platform technologies.
Do we feel like Google's efforts are a ... viable thing yet?
Not really sure the Sony and MS thing are a reaction, and I'm not sure Google's thing is so much a thing.
Some of Google's PR about how whatever it is they're doing is going to be all things (their statements have been strange IMO) could just be unfocused PR, or just an unfocused product.
Presumably if Google makes game development for Linux commercially viable, that will make for much more vibrant community support (tooling etc.) for local Linux as well. That plus what Valve is doing with Proton could potentially break the stranglehold Windows has on PC gaming. I personally would go 100% linux on my media PC if I did not occasionally play games on Windows.
They most likely wont be released, but the hope is that google contributes to open source like vulkan, linux video drivers, graphics rendering, as well as potentially release their own tooling.
Some of them not (from legacy publishers). Others from normal ones will, especially since they'll see it as "why not reach more users, we already did all the heavy lifting anyway", instead of legacy publishers' scornful "why do it, who is using Linux?".
In their context, lock-in could happen if they'll start pushing exclusives. But in technology sense, they are advancing common stack (Linux / Vulkan), unlike MS and Sony who use tools lock-in to discourage platform development by making it more costly.
Can you explain how its not a lock-in? It seems to require a Google account and is limited to games that are blessed by google. AFAIK, I don't think I can download Stadia and run it on a home server and stream games to multiple PCs in my own home. If Google made it open source, then yes, I'm 100% with you...
The graphics API isn't that big a deal anymore. It's often a pretty small part of the engine codebase. Many games, especially those built on the popular engines like Unity, support both DirectX and Vulkan (and Sony's API too).
It is a lot bigger deal than you think, including for those very engine developers who work on Unity and etc. Having to deal with all extra lock-in APIs doesn't come for free. It takes time, resources and slows down releasing features to their users.
Vulkan _is_ a lock-in API, locking you into Google platforms; the one commercially viable platform using it is [recent versions of] Google's Android with another one on the horizon - Google Stadia. It's not necessary on Windows, not available on two of the three consoles, and not available without a wrapper on iOS and OSX.
(Technically, it is also available on Nintendo Switch, but there's also an arguably better alternative there.)
What? Vulkan is cross platform, not limited to Google or anyone else. You want Vulkan on your hardware and your OS? No one is stopping you from making a driver for it, it's an open API. For example, radv was made as Vulkan driver for AMD on Linux without AMD directly involved even (with big contributions from Valve).
If MS and Sony wanted, they could have Vulkan driver for Xbox and PlayStation tomorrow, since they are all using AMD GPUs. And no one stopped Apple from supporting Vulkan on their systems either. They don't, since they are also lock-in jerks, which is exactly the point I was making above.
That's just plain incorrect. There are already mainstream AAA titles targeting Vulkan published for Windows and macOS (via MoltenVK). Doom Eternal will only target Vulkan on PC
: https://en.wikipedia.org/wiki/Id_Tech_7
And OpenGL and Metal, and even the web! With a sweeping generalisation I'm going to say that a games company is either too small to care about the graphics API, or too big to care.
Tell that to graphics programmers. Imagine how much better performance you could expect from games if they could spend their time optimizing for one API, and not making compromises to target a half dozen.
> Imagine how much better performance you could expect from games if they could spend their time optimizing for one API, and not making compromises to target a half dozen.
That is not really an accurate statement. Graphics performance is heavily dependent on the actual hardware design of the underlying platform. You can't wave a magic API-wand and have your executable or shader be magically fast on every hardware platform.
It also depends on design of the engine, which can be improved, instead of spending time on supporting a lot of redundant APIs. Support for lock-in is essentially a tax put on developers, and it's exactly the way lock-in proponents want it.
Why couldn't it, you dont think software updates can improve performance across the board? But his point was developers could focus on a single api rather than having to deal with quirks in directx, opengl, vulkan, webgl, etc.
>But his point was developers could focus on a single api rather than having to deal with quirks in directx, opengl, vulkan, webgl, etc.
That is really an imagined scenario. An extremely tiny minority of games are targeted for such a wide variety of platforms. Real-time high-performance code is always tightly coupled with the hardware - if you want to squeeze performance out of hardware, you want to minimize abstractions to such a level as they don't hurt your productivity. If you're targeting consoles, you can maybe target the PC platform. But there is no way you're targeting the nintendo DS or a smartphone with the same codebase without major modifications to the graphics code.
> An extremely tiny minority of games are targeted for such a wide variety of platforms.
On the contrary, most games are targeted for most platforms, to increase reach and sales as result of it. Only some exclusives of console makers are not doing that, and those are clearly outliers.
> Real-time high-performance code is always tightly coupled with the hardware
That's not common at all. Unless you want to beat modern compilers with assembly code, you only will produce something worse. Sure, there are are rare cases when using hardware specific features yields extra performance. Codec developers do that for example. But for games? Not usually needed. Shaders are provided in cross platform fashion (such as SPIR-V) and that's compiled into GPU machine code by the driver. And actual game code is commonly using some high level systems language (C++, etc.) + a scripting one.
Good performance is achieved by parallelizing the engine properly, since modern hardware is increasingly multicore.
How does Stadia advance Linux+Vulkan? The games run in a data center (and they're not running a standard Linux port, the presentations I saw made it sound like they were running basically another console port).
More gaming developers becoming familiar with Linux+Vulkan, more games ported to Stadia's Linux, all that means more potential releases for normal desktop Linux as well. Not all who target Stadia will clearly do it, but potential is surely better than without Stadia. So I see it as net positive for Linux gaming.
The Xbox One has an NT kernel and DirectX as the graphics API. Stadia's use of Linux and Vulkan are probably about as helpful for a port to desktop Linux as an Xbox One game is for a Windows port.
That analogy is the biggest thing to happen for Linux porting since Valve's Proton SDK - all future MS-funded Xbox One games do come to Windows (albeit as UWPs) and run great.
You mean, the project Google will cancel in 3 years? Yeah, I'm sure the two gaming behemoths that have been demoing the cloud working in conjunction with games for the past decade made their decision based on that. Microsoft demoed cloud compute doing physics calculations in games...what? 8 years ago? Sony already has a game streaming service. Microsoft is expected to make an announcement this E3 on the topic.
Microsoft and Sony want to be relevant in a mobile world too...that's what this is all about. They both were shutout of the mobile piece of the pie in gaming, and they are coming back for it. Microsoft and Sony want their gaming ecosystem on mobile devices with the ability to cross-play with wired devices powered by their SaaS models, Xbox Live and Playstation Online. That market is much bigger than the market they've already captured.
I'd be happy if Valve became a middleperson for AAA titles native on Linux+Vulkan. They have SteamOS and a decent controller ready to resurrect, and everyone to slap on PC hardware consoles again, given a makeover.
I'm not convinced they have the core competencies required to pull it off. It seemed like they had the hype and market positioning to pull it off the first time around, but just expected 3rd party hardware vendors to do the work and make SteamBox a thing via the magic of the free market. I think it might have worked if they put together an excellent 1st party product and gave it a real marketing push.
It would've helped if the top titles were there. (If you bought/built a SteamOS box, you have a rough-looking thing that doesn't play top games, when you could instead just run Windows+Steam, or get a Sony or MS console, any of which would play most things.)
Valve seemed to not make the final marketing push on Steam Machines, that I could see. Maybe because they realized that it wasn't coming together. And/or maybe it was intended as a warning, to not be forced out when MS was grabbing the app store.
Your idea of Valve in making a console themselves is interesting. They did get some limited experience with hardware, with the controller and the thin device. I don't know what all would go into some kind of manufacturing and branding partnership.
One thing that I think didn't happen is an initial loss-leader on the console, to bring people into the lock-in ecosystem, like the console companies might do. I don't see how the third parties had that incentive. And I don't know how loss-leader works if whatever anyone builds is just a commodity PC.
Wine and Proton are exactly the type of solution that I want. It works and it will get better every year. Linux users can run software without explicit vendor support. (software freedom 0 [0]) It doesn't burden corporations with expensive Linux support. Everyone is happy.
The FSF is frequently misled by volunteers into bad strategy moves for its goals. RMS's criteria of "is it Free" is insufficient, and also easily exploited, just by spinning your thing to check off the checklist boxes.
> The inside story of how DOOM came to life on Stadia. id Software delivers a bird’s eye view of real-world Stadia development from conception to execution. Learn how high-performance games are made on Google’s new streaming platform. Recorded at GDC 2019.
Yeah but Google has serious bonafides as far as delivering high-res video at scale. Stadia is just Youtube with input handling and a game renderer instead of video files producing the frames.
'Just'? I'd say game streaming is an order of magnitude more difficult of a problem. YouTube has high throughput yes, but latency is the far more difficult problem, and potentially unsolvable with American ISPs the way they are.
I'm going to bet that YouTube's experiences with interframe compression will help them out a lot in this regard, as it could help them remove some of the data they need to transmit.
Wrong. Microsoft perfected this years ago with their Azure hosted desktop product. They’ve been working on high-res compression of GPU frames before Google even put a dedicated GPU cluster in their data centers
Absolutely not. Game developers have deep deep knowledge in making games for Windows and PlayStation type OS’+hardware. Studios aren’t going to spend years having their devs relearn nuances specific to Google’s Linux implementation
They totally will, if Google will wave the huge user base size in front of them (which Google already did). So MS grip on gaming developers' mind share will fly out of the windows. That's the best thing I see coming out of Stadia and it's something MS clearly are scared of, since when it comes to their gaming business, they are used to lock-in and years of developers' mind share domination, rather than competition on merit.
