Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

Google have now finally unveiled their new cloud gaming service named Stadia, offering instant access to play games in Google Chrome.

What they joked was the worst-kept secret in the industry (no kidding), sounds like quite an interesting service. Certainly one that could eventually end up redefining what gaming is. A little hyperbolic maybe? I'm not so sure considering how easy this should be to jump into a game. On top of that, they very clearly talked about how it's built on Linux (Debian specifically) and Vulkan with custom GPUs from AMD.

Something they showed off, was how you could be watching a game trailer with a button to play it on Stadia and (supposedly within a few seconds) you would jump right into it. That's quite en exciting idea, one that would easily pull in quite a lot of people I've no doubt.

As for resolution, they said it will support 1080p and 4K around 60FPS at release with 8K being worked on as well but that sounds further out if anyone even cares about 8K right now.

They also showed off their new controller, with a dedicated Google Assistant button and a button to capture video immediately for YouTube:


While Google are making their own dedicated gamepad, they did say it will be compatible with other devices too.

They also announced partnerships with both Unity and Unreal Engine and Stadia will "embrace full cross-platform play" including "game saves and progression". They also had id Software, talk about how it didn't take long to bring the new Doom Eternal to Stadia, thanks to how they made the previous Doom game with Vulkan.

This means, that development for Linux is suddenly going to become a priority for a lot more developers and publishers. I don't want to overstate how important that is, but it's a very exciting prospect. This doesn't suddenly mean we're going to see a lot more Linux games on the desktop, but it's entirely possible after they go through all the work to get the games working on Linux with Vulkan for Stadia.

Stream Connect is another service they talked about. They mentioned how developers have pushed the boundaries of gaming but often local co-op is left out, as doing it multiple times in top-end games can require really beefy hardware. With Stadia, each instance would be powered by their servers so it wouldn't be such an issue. They also talked about how if you're playing some sort of squad-based game, how you could bring up their screen to see what they're doing which sounds very cool.

Google also announced the formation of their own game studio, Stadia Games and Entertainment, to work on exclusive games for their new service.

As for support from more external game developers, they mentioned how they've shipped "development hardware" to over 100 developers. From what they said, it should be open to smaller developers as well as the usual AAA bunch.

Stadia is confirmed to be launching this year and it will be first available in the US, Canada, UK and "most of Europe". One thing wasn't mentioned at all—price, but they said more details will be available in the summer. The official site is also now up on stadia.com and developers have their own website to look over.

Google also posted up some extra information on their developer blog:

Google believes that open source is good for everyone. It enables and encourages collaboration and the development of technology, solving real-world problems. This is especially true on Stadia, as we believe the game development community has a strong history of collaboration, innovation and shared gains as techniques and technology continually improve. We’re investing in open-source technology to create the best platform for developers, in partnership with the people that use it. This starts with our platform foundations of Linux and Vulkan and shows in our selection of GPUs that have open-source drivers and tools. We’re integrating LLVM and DirectX Shader Compiler to ensure you get great features and performance from our compilers and debuggers. State-of-the-art graphics tools are critical to game developers, and we’re excited to leverage and contribute to RenderDoc, GAPID and Radeon GPU Profiler — best of breed open-source graphics debugging and profiling tools that are continually improving.

There's probably plenty I missed, you can see their video on YouTube here.

As exciting and flashy as it sounds, it's obviously not Linux "desktop" gaming which is what the majority of our audience is likely interested in. However, things change and if it does become a huge hit we will cover it more often if readers request it. Linux gaming can mean all sorts of things from native games to emulators, Wine and Steam Play and now perhaps some cloud gaming so I don't want to rule it out. However, I can't see this replacing Steam, Humble, GOG, itch.io and so on for me personally.

Obviously there’s still a lot of drawbacks to such a service, especially since you will likely have zero ownership of the actual games so they could get taken away at any time when licensing vanishes. At least with stores like Steam, you still get to access those games because you purchased them. Although, this does depend on what kind of licensing Google do with developers and publishers, it might not be an issue at all but it’s still a concern of mine. Latency and input lag, are also two other major concerns but given Google's power with their vast networks, it might not be so bad.

Also, good luck monitoring your bandwidth use with this, it's likely going to eat up a lot all of it. YouTube and Netflix use up quite a bit just for watching a 30-minute episode of something in good quality, how about a few hours per day gaming across Stadia? Ouch.

That doesn't even address the real elephant in the room, you're going to be giving Google even more of your data if you use this service, a lot more. This is the company that failed to promptly disclose a pretty huge data leak in Google+ after all. I don't want to be some sort of scaremongering crazy-person but it's something to think about.

As always, the comments are open for you to voice your opinion on it. Please remain respectful to those with a different opinion on the matter.

Article taken from GamingOnLinux.com.
52 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
285 comments
Page: «27/29»
  Go to:

Shmerl Mar 27, 2019
Quoting: GuestWithout seeing the Stadia SDK, I suspect their input handling is very similar to that provided by SDL2 (if not a modified version of SDL2 itself), or can be easily wrapped into existing input abstraction. So the game engine sees it as just normal input rather than anything more fancy.

That's why I don't think a wrapper is necessary.

If they aim to be compatible with SDL2 - even better. But so far there are not enough details on this.
etonbears Mar 27, 2019
Quoting: Shmerl
Quoting: GuestNo actually sure what's being asked for here. It was mentioned that for the "PC Vulkan port" there was essentially one file different to that maintained for Stadia. No wrapper is needed - it already works, mostly because they want to test it locally. And in this case, Ubisoft wasn't being lazy - they are indeed trying to do things proper (for reasons of Stadia, but it helps desktop regardless), and some of their feedback into tooling has been helping AMD (and Google) focus on those areas.

So what would the wrapper be used for really? I mean, all the middleware problems, input, networking, audio, etc, had to be resolved to make it work with Stadia anyway. So I'm not sure what's really left for a wrapper to do (compared to a Stadia port).

Stadia is different from our regular desktop use case. Think about how it handles input. It's routed to the game from the network, not from your local keyboard and mouse attached to the computer. Same way, output doesn't go to regular Vulkan swapchains aimed at the display, it's packed into some video stream, sent out to the user.

If I understood correctly, Stadia SDK provides those features in the form of some API for the developers. So taking Stadia game as is won't work locally, without going through some unnecessary clunky client server setup (and it's not clear even if the server side of Stadia is open source).

So to convert that into a proper desktop usable code, something needs to be changed. Or some kind of shim implemented like above.

Proper changes might be small, but Ubisoft is too lazy to do even that small amount. Shim might make it practically seamless, though knowing Ubisfot or Bethesda, even that won't help them ;)

I would guess that Stadia input reader, reading your controller/mouse/keyboard over WIFI probably just packs/sends/unpacks events and then forwards them to the game; and as you say the output is packed to a network stream instead of a local screen buffer.

You might be able to simply ship the thin-client, input reader and some sort of game/Stadia code mash to all run on one machine as a "local" game, but I doubt the performance would be good.

As developers use more of the Stadia server instance-to-instance features, this would break down as well.

A lot of Stadia code would probably remain usable in desktop Linux, but it would still need a fair amount of work to package it differently, and, more importantly, test and optimize for the wide variety of hardware targets represented by the desktop.

The main advantage from Stadia development, for Linux gamers ( unless you like streaming ) may be the improved tooling and greater Linux knowledge in the Developer community. People are constantly leaving existing developers and starting new companies; the more Linux know-how they take with them, the better.
etonbears Mar 27, 2019
Quoting: Guest
Quoting: Shmerl
Quoting: GuestNo actually sure what's being asked for here. It was mentioned that for the "PC Vulkan port" there was essentially one file different to that maintained for Stadia. No wrapper is needed - it already works, mostly because they want to test it locally. And in this case, Ubisoft wasn't being lazy - they are indeed trying to do things proper (for reasons of Stadia, but it helps desktop regardless), and some of their feedback into tooling has been helping AMD (and Google) focus on those areas.

So what would the wrapper be used for really? I mean, all the middleware problems, input, networking, audio, etc, had to be resolved to make it work with Stadia anyway. So I'm not sure what's really left for a wrapper to do (compared to a Stadia port).

Stadia is different from our regular desktop use case. Think about how it handles input. It's routed to the game from the network, not from your local keyboard and mouse attached to the computer. Same way, output doesn't go to regular Vulkan swapchains aimed at the display, it's packed into some video stream, sent out to the user.

If I understood correctly, Stadia SDK provides those features in the form of some API for the developers. So taking Stadia game as is won't work locally, without going through some unnecessary clunky client server setup (and it's not clear even if the server side of Stadia is open source).

So to convert that into a proper desktop usable code, something needs to be changed. Or some kind of shim implemented like above.

So in the talk, I was under the impression that local builds did not rely on the Stadia SDK. The main difference was the swapchain initialisation for them, which yes must be different because of framebuffer output to some kind of video encoder (and as an aside, which might come more natively to Vulkan one day, as mentioned in another talk) instead of a monitor. A single file. I suspect a few minor changes elsewhere, but obviously nothing worth mentioning. See about seven and a half minutes into the talk.

Without seeing the Stadia SDK, I suspect their input handling is very similar to that provided by SDL2 (if not a modified version of SDL2 itself), or can be easily wrapped into existing input abstraction. So the game engine sees it as just normal input rather than anything more fancy.

That's why I don't think a wrapper is necessary.

I'm sure you're right. This was a port of an existing single-player game, so it would expect to have a simple I/O model. It would probably be relatively easy to have a run-time switch in a Stadia game to direct the input/output differently, but that would be part of the SDK.

A wrapper could do the same by hooking the Vulkan loader with an implicit layer that pushes output to a local screen instead of the Stadia network stream, but we don't know enough about the rest of Stadia architecture to judge input handling, and whether the game code remains an independent executable outside the server.
Sir_Diealot Mar 28, 2019
What about those Stadia boxes for developers that we have seen? Any clue how they work? I guess they are a local Stadia environment to develop on and test on LAN? Could also be that it does client/server in the box.Probably easier and closer to the real thing than having a non-c/s client.
etonbears Mar 28, 2019
Quoting: Sir_DiealotWhat about those Stadia boxes for developers that we have seen? Any clue how they work? I guess they are a local Stadia environment to develop on and test on LAN? Could also be that it does client/server in the box.Probably easier and closer to the real thing than having a non-c/s client.
Information seems to be rather sparse unless you ask to join the developer program. You need an existing game project to do that.

I am not sure which "boxes" you are referring to, but I think the "free stadia workstation nodes" Google are offering are likely to be more focused around integrated Linux tooling rather than runtime. Google do seem to recognise they need to provide a comparable set of developer services to the console vendors if they want to get large-scale adoption.
Shmerl Apr 4, 2019
Quoting: ShabbyXGoogle is huge, and so is the amount of feedback they get. Depends on the team, but they usually go through everything, even if they can't literally reply to everyone. Probably the first step would be to wait for launch, then submit feedback through whatever interface they have. Mind you, they could disagree with the suggestion or have it as low priority, but they won't be able to engage with you personally due to the massive amount of feedback they get.

I posted the proposal here: https://www.reddit.com/r/Stadia/comments/b977ex/proposal_for_google_stadia_provide_drmfree/

Stadia subreddit has an official community manager from Google. So I guess this is as good as it gets, if she can help directing this to anyone in the company who could use such idea.


Last edited by Shmerl on 4 April 2019 at 2:52 am UTC
Zlopez Apr 4, 2019
  • Supporter Plus
Quoting: ShmerlI posted the proposal here: https://www.reddit.com/r/Stadia/comments/b977ex/proposal_for_google_stadia_provide_drmfree/

Stadia subreddit has an official community manager from Google. So I guess this is as good as it gets, if she can help directing this to anyone in the company who could use such idea.

I read your subreddit and it's nice how you are trying to explain how DRM is wrong and it shouldn't be used. I myself always wonder, why the DRM is even used, when it doesn't affects sales. Who doesn't want to pay never will, with or without DRM. I agree with the movies, it is the most sick industry in regards of DRM.

I'm even convinced, that the sales wouldn't be affected if every software will be open sourced.
Shmerl Apr 4, 2019
Quoting: ZlopezI read your subreddit and it's nice how you are trying to explain how DRM is wrong and it shouldn't be used. I myself always wonder, why the DRM is even used, when it doesn't affects sales. Who doesn't want to pay never will, with or without DRM. I agree with the movies, it is the most sick industry in regards of DRM.

I'm even convinced, that the sales wouldn't be affected if every software will be open sourced.

Feel free to comment in that thread. It's surprising how many DRM proponents are commenting there. I suspect most of them aren't sincere users, but represent the pro-DRM side of publishers.


Last edited by Shmerl on 4 April 2019 at 11:33 am UTC
Zlopez Apr 4, 2019
  • Supporter Plus
Quoting: ShmerlFeel free to comment in that thread. It's surprising how many DRM proponents are commenting there. I suspect most of them aren't sincere users, but represent the pro-DRM side of publishers.

Probably, because I can't understand why any gamer wants to promote DRM gaming. Don't know much of the gamers, that are happy, when the game can't be played offline or not starting because of DRM.
Salvatos Apr 4, 2019
Quoting: Zlopez
Quoting: ShmerlFeel free to comment in that thread. It's surprising how many DRM proponents are commenting there. I suspect most of them aren't sincere users, but represent the pro-DRM side of publishers.

Probably, because I can't understand why any gamer wants to promote DRM gaming.
A false sense that they are protecting an industry they care about, probably.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.