You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal!

Windows 10 S might alarm Valve into boosting SteamOS again

Posted by , | Views: 34,010

You might have heard of Microsoft's latest plans (source) to keep people on their own store, with a locked down Windows 10 S mode to be available on all versions of Windows. This is easily a first step towards Windows 10 S being the first version of Windows that users see.

Windows 10 S is essentially a version of Windows 10 that's locked into the Windows Store with Universal Windows Platform (UWP) apps, so you can't really run traditional applications like Steam and so on.

This goes directly back to how Gabe Newell of Valve and plenty of other developers felt about Windows 8. With Newell saying "I think Windows 8 is a catastrophe for everyone in the PC space.". There's also Croteam CTO Alen Ladavac who wasn't too pleased with it either, he's now tweeted about this latest issue from Microsoft to say " 'I told you so' doesn't quite cut it. :P". Ladavac also said in a reply "Think about it - if apps need to be adapted for UWP, it might be wiser to just adapt them for OSX/Linux instead.".

It makes sense too, if Microsoft is determined to make Windows more locked-down over time, that's not really good for anyone. Actually investing into Linux gaming, where you have far more control opens you up to many more opportunities.

Apparently, Windows 10 S can be upgraded to a "normal" version of Windows 10 Home for free, but the problem is that Microsoft has said around 60% don't even bother to do the upgrade keeping them locked into the Windows Store.

I hope Valve is keeping an eye on this, and it should certainly make Linux and SteamOS quite attractive again for them. There's good reasons why Valve has kept SteamOS around and plans like this from Microsoft (even if they fall through) will happen again and again. If Microsoft fail, they will wait a while and try it another way.

How long will it be until you have to pay to upgrade to Windows 10 Home, how long before the Home edition doesn't exist? Many questions—questions which should probably alarm people.

Thanks for the tip kellerkindt. Note: Article intro updated after publishing to better reflect my own point.

38 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more information here.
127 comments
Page: «13/13
  Go to:

appetrosyan 11 February 2018 at 12:21 pm UTC
tuubi
appetrosyanRight now the biggest one I face, is the fact that in a complex scene, the rendering speed drops. this all due to the way in which frames are buffered in X.org, and is one of the main reasons why the switch is being made.
OpenGL and Vulkan drivers on Linux make use of direct rendering, communicating directly with the hardware. Frames are not presented through an X.org buffer. What you said is mostly true, but it doesn't affect gaming that much.

Last I checked Vulkan was supported by Croteam (who are doing a great job an away) and Bethesda, (who make great games, and don't support Linux). When we get native support that circumvents the issues of X.org and the common ways of porting games (e.g. SDL) start making use of Vulkan, we're in business.
Samsai 11 February 2018 at 12:39 pm UTC
appetrosyan
tuubi
appetrosyanRight now the biggest one I face, is the fact that in a complex scene, the rendering speed drops. this all due to the way in which frames are buffered in X.org, and is one of the main reasons why the switch is being made.
OpenGL and Vulkan drivers on Linux make use of direct rendering, communicating directly with the hardware. Frames are not presented through an X.org buffer. What you said is mostly true, but it doesn't affect gaming that much.

Last I checked Vulkan was supported by Croteam (who are doing a great job an away) and Bethesda, (who make great games, and don't support Linux). When we get native support that circumvents the issues of X.org and the common ways of porting games (e.g. SDL) start making use of Vulkan, we're in business.
SDL doesn't really "make use of Vulkan" (unless you use just SDL's built-in graphics routines and even then I think it might just use OpenGL). What you do with SDL is make a window, load up Vulkan and create a Vulkan context/surface/whatever onto that window and start pushing data and commands to the GPU to do things with that surface. The support for doing this was released in last September.

Vulkan and Wayland are quite probably not going to be some kind of silver bullets that will solve the performance issues. Vulkan will allow devs to possibly tweak their games more and parallelize their rendering more than OpenGL allows but that'll largely depend on the devs' ability to make efficient code. As for Wayland, it's not really much of a performance boost. I've used it for a couple of months now and the only real difference between X.org and Wayland is that window movement is a bit smoother, 3D performance is more or less equal between the two.
Guest 11 February 2018 at 1:29 pm UTC
GrazenBut isn't Microsoft alreadly making S-Mode or UWP games - pretty well everything they publish on the Xbox is cross compatible with UWP.

Yes, they made UWP, and they made special Windows 10 S versions, which for gaming are UWP exclusive.
What seems to be coming next are pre-installed Windows versions which could default to a new S mode, if/when OEMs want to save money and do as MS pleases. This S mode is UWP exclusive if not switched off by the user. Switching off S mode (I believe) will be accompanied by security warnings, and (as they say) will cost 50$ on everything above Home Edition. On Home Edition it is said to be free.
appetrosyan 11 February 2018 at 6:10 pm UTC
Samsai
appetrosyan
tuubi
appetrosyanRight now the biggest one I face, is the fact that in a complex scene, the rendering speed drops. this all due to the way in which frames are buffered in X.org, and is one of the main reasons why the switch is being made.
OpenGL and Vulkan drivers on Linux make use of direct rendering, communicating directly with the hardware. Frames are not presented through an X.org buffer. What you said is mostly true, but it doesn't affect gaming that much.

Last I checked Vulkan was supported by Croteam (who are doing a great job an away) and Bethesda, (who make great games, and don't support Linux). When we get native support that circumvents the issues of X.org and the common ways of porting games (e.g. SDL) start making use of Vulkan, we're in business.
SDL doesn't really "make use of Vulkan" (unless you use just SDL's built-in graphics routines and even then I think it might just use OpenGL). What you do with SDL is make a window, load up Vulkan and create a Vulkan context/surface/whatever onto that window and start pushing data and commands to the GPU to do things with that surface. The support for doing this was released in last September.

Vulkan and Wayland are quite probably not going to be some kind of silver bullets that will solve the performance issues. Vulkan will allow devs to possibly tweak their games more and parallelize their rendering more than OpenGL allows but that'll largely depend on the devs' ability to make efficient code. As for Wayland, it's not really much of a performance boost. I've used it for a couple of months now and the only real difference between X.org and Wayland is that window movement is a bit smoother, 3D performance is more or less equal between the two.

I would suggest you read my comment a bit more carefully. You are completely right, but I feel that I need to point out a few things.

First of all, when game development shifts towards Vulkan in lieu of DirectX we will not have a distinct disadvantage, as porting a game will no longer involve porting the most difficult part of the rendering pipeline. It will bring Linux and Windows onto the same footing in terms of graphical optimisations. It's not a silver bullet, but it's sure going to help us make a good case for linux gaming. It will definitely help out with the emulation: wine gives you Windows level performance on Doom and Wolfenstein using Vulkan, meaning that we can shrug off - "But you don't have as many games" by saying "Yeah we do. You can run everything you could on windows".

Secondly, Wayland's improved performance stems from a few factors. Most of the applications and games still use X.org, which means that you couldn't detect a performance increase, mostly because you were running it through the same graphical pipeline. If you don't have Wayland running in the background, you will see the difference. Also, Wayland decouples some of the hardware from the software, which (if the developers listen to reason) will allow us to do Windows level customisation to Gaming peripherals. Right now, the only way of creating keyboard macros is bound to x.org. Once we have enough people running wayland full time, we will be able to convince them to let us do some of those things: pass keypresses to specific applications (in gamer world terms 'tis a must).
Samsai 11 February 2018 at 6:18 pm UTC
appetrosyan
Samsai
appetrosyan
tuubi
appetrosyanRight now the biggest one I face, is the fact that in a complex scene, the rendering speed drops. this all due to the way in which frames are buffered in X.org, and is one of the main reasons why the switch is being made.
OpenGL and Vulkan drivers on Linux make use of direct rendering, communicating directly with the hardware. Frames are not presented through an X.org buffer. What you said is mostly true, but it doesn't affect gaming that much.

Last I checked Vulkan was supported by Croteam (who are doing a great job an away) and Bethesda, (who make great games, and don't support Linux). When we get native support that circumvents the issues of X.org and the common ways of porting games (e.g. SDL) start making use of Vulkan, we're in business.
SDL doesn't really "make use of Vulkan" (unless you use just SDL's built-in graphics routines and even then I think it might just use OpenGL). What you do with SDL is make a window, load up Vulkan and create a Vulkan context/surface/whatever onto that window and start pushing data and commands to the GPU to do things with that surface. The support for doing this was released in last September.

Vulkan and Wayland are quite probably not going to be some kind of silver bullets that will solve the performance issues. Vulkan will allow devs to possibly tweak their games more and parallelize their rendering more than OpenGL allows but that'll largely depend on the devs' ability to make efficient code. As for Wayland, it's not really much of a performance boost. I've used it for a couple of months now and the only real difference between X.org and Wayland is that window movement is a bit smoother, 3D performance is more or less equal between the two.
Secondly, Wayland's improved performance stems from a few factors. Most of the applications and games still use X.org, which means that you couldn't detect a performance increase, mostly because you were running it through the same graphical pipeline. If you don't have Wayland running in the background, you will see the difference. Also, Wayland decouples some of the hardware from the software, which (if the developers listen to reason) will allow us to do Windows level customisation to Gaming peripherals. Right now, the only way of creating keyboard macros is bound to x.org. Once we have enough people running wayland full time, we will be able to convince them to let us do some of those things: pass keypresses to specific applications (in gamer world terms 'tis a must).
3D applications that use system SDL already have access to native Wayland and I've also built some games from source so that they utilize system SDL and thus shouldn't be running through XWayland. In both cases I have seen no noticeable performance benefits. X.org just isn't the bottleneck with game performance, sub-optimal OpenGL is.
Shmerl 11 February 2018 at 6:54 pm UTC
Did SDL solve relative mouse cursor positioning issue on Wayland?
appetrosyan 12 February 2018 at 5:54 pm UTC
Samsai
appetrosyan
Samsai
appetrosyan
tuubi
appetrosyanRight now the biggest one I face, is the fact that in a complex scene, the rendering speed drops. this all due to the way in which frames are buffered in X.org, and is one of the main reasons why the switch is being made.
OpenGL and Vulkan drivers on Linux make use of direct rendering, communicating directly with the hardware. Frames are not presented through an X.org buffer. What you said is mostly true, but it doesn't affect gaming that much.

Last I checked Vulkan was supported by Croteam (who are doing a great job an away) and Bethesda, (who make great games, and don't support Linux). When we get native support that circumvents the issues of X.org and the common ways of porting games (e.g. SDL) start making use of Vulkan, we're in business.
SDL doesn't really "make use of Vulkan" (unless you use just SDL's built-in graphics routines and even then I think it might just use OpenGL). What you do with SDL is make a window, load up Vulkan and create a Vulkan context/surface/whatever onto that window and start pushing data and commands to the GPU to do things with that surface. The support for doing this was released in last September.

Vulkan and Wayland are quite probably not going to be some kind of silver bullets that will solve the performance issues. Vulkan will allow devs to possibly tweak their games more and parallelize their rendering more than OpenGL allows but that'll largely depend on the devs' ability to make efficient code. As for Wayland, it's not really much of a performance boost. I've used it for a couple of months now and the only real difference between X.org and Wayland is that window movement is a bit smoother, 3D performance is more or less equal between the two.
Secondly, Wayland's improved performance stems from a few factors. Most of the applications and games still use X.org, which means that you couldn't detect a performance increase, mostly because you were running it through the same graphical pipeline. If you don't have Wayland running in the background, you will see the difference. Also, Wayland decouples some of the hardware from the software, which (if the developers listen to reason) will allow us to do Windows level customisation to Gaming peripherals. Right now, the only way of creating keyboard macros is bound to x.org. Once we have enough people running wayland full time, we will be able to convince them to let us do some of those things: pass keypresses to specific applications (in gamer world terms 'tis a must).
3D applications that use system SDL already have access to native Wayland and I've also built some games from source so that they utilize system SDL and thus shouldn't be running through XWayland. In both cases I have seen no noticeable performance benefits. X.org just isn't the bottleneck with game performance, sub-optimal OpenGL is.

Fair.

What games?
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon or Liberapay. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

We also accept Paypal donations and subscriptions! If you already are, thank you!

Due to spam you need to Register and Login to comment.


Or login with...

Livestreams & Videos
Community Livestreams
See more!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts