Recently, a Valve developer revived steamcompmgr (the SteamOS compositing and window manager) and renamed it to Gamescope. After writing about it yesterday here on GOL, they've now given some more info on what it actually does.
Valve developer Pierre-Loup Griffais is spearheading the effort and a few hours ago they actually gave it a readme, mentioning that "gamescope does the same thing as steamcompmgr, but with less extra copies and latency". From the readme:
- It's getting game frames through Wayland by way of Xwayland, so there's no copy within X itself before it gets the frame.
- It can use DRM/KMS to directly flip game frames to the screen, even when stretching or when notifications are up, removing another copy.
- When it does need to composite with the GPU, it does so with async Vulkan compute, meaning you get to see your frame quick even if the game already has the GPU busy with the next frame.
It also runs on top of a regular desktop, the 'nested' usecase steamcompmgr didn't support.- Because the game is running in its own personal Xwayland sandbox desktop, it can't interfere with your desktop and your desktop can't interfere with it.
- You can spoof a virtual screen with a desired resolution and refresh rate as the only thing the game sees, and control/resize the output as needed. This can be useful in exotic display configurations like ultrawide or multi-monitor setups that involve rotation.
The features of that second part are working, but aren't exposed to the user yet.
Right now, they said it runs on an AMD GPU with Mesa but could be made to work with other drivers "with minimal work". NVIDIA would need to support accelerated Xwayland to work with Gamescope.
Definitely going to be interesting to find out their actual plan for it. A revived Steam Machine effort, perhaps with an AMD GPU? Or something else to help with whatever Steam Cloud Gaming turns out to be—a simple Linux front end for it perhaps? Back down to reality for a moment, it's more likely it's linked to their container effort to make Linux games run exactly how they want them across the many different distributions and desktops.
Many questions. I've emailed Valve to see if they want to give us any insight, although they're usually tight-lipped though so we might have to just wait and see if it's for a big plan or just a fun project for now.
Article taken from GamingOnLinux.com.
Mohandevir Jan 16, 2020
Quoting: NociferWell, now I can't help but feel absolutely certain that Nvidia's "big open source announcement" scheduled for March 23-26 (more info will be to reveal their top secret business partnership with Valve, aiming to produce the next generation of Steam Cuda™ Machines, running on an open core Wayland stack, as a masterfully orchestrated counterattack to AMD's partnerships with Sony and MS as regards to providing the GPUs for PS5 and XboxNext.
I'm calling it first folks: the Year of the Linux Desktop (2020 Edition) is finally upon us, and it's all thanks to Nvidia. Rejoice.
Spoiler, click me
(Bad) jokes aside, Valve's continuing dedication to the future of Linux as a competent gaming platform throughout the past decade is truly praiseworthy. Many, many kudos to them!
A "little" overoptimistic and funny. :D
Last edited by Mohandevir on 16 January 2020 at 9:16 pm UTC
good bye obs
Quoting: elmapul'- Because the game is running in its own personal Xwayland sandbox desktop, it can't interfere with your desktop and your desktop can't interfere with it.'
good bye obs
Wayland cases for screen capturing should be handled with Pipewire if I understood correctly. Not sure if OBS is using it yet.
Quoting: MohandevirI made the choice of a GTX 1660 Super because it was the best GPU for the 450W PSU in my Mini-itx build and I use a lot of in-home streaming... For these use-cases, I'm kind of stuck with Nvidia. AMD as the tendency to have an higher tdp, unfortunately... Don't know if it's going to change with the RX5600XT.
Yeah, in power efficiency, Nvidia is still ahead. RDNA was the first step to close the gap, and from what I've read, developers of Zen architecture are focusing on increasing power efficiency of it. So would be interesting to see how it will evolve with RDNA 2.
On occasion I record my games (never have performed live cast) and I do like to do so for the occasional tut for friends and family.
I have read about that AMD and Intel hardware are now able to leverage VAAPI to use hardware encoders for screen capture be it with OBS or other programs, and OBS only recently (release 24 I think?) added such support.
Now in terms of performance I am a bit sceptic. nVenc has come a long way from lesser Kepler (GTX 600) to Pascal and current Turing boards. I did notice a HUGE difference both in quality and performance when using nvenc on my older desktop GTX 760 card, the laptop's GTX 950 (when running only the blob, so no hybrid graphics) and my current desktop's 1080 (non Ti, and I believe that the jump from Pascal to Turing for nvenc is of about 20%), from Kepler to Maxwell was the biggest jump than from Maxwell to Pascal, which was noticeable, but not as noticeable as the previous, and seems to be a similar case with Pascal to Turing. With my GTX 760 just recording the desktop (in Linux) I could have some dropped frames (dunno if that was the case on Windows as well, might have been a driver issue altogether) and sure enough driver maturity has come a long way for nvidia (even though I am fully aware they care next to nothing about its customers).
Now, what performance, encoder (support and settings), and general quality can you expect to achieve when using hardware encoding on a modern Intel/AMD part in Linux? Especially interesting would be to know if you see an actual performance hit on your gaming (for instance) when using it.
I'm sure this will be of particular interest to that segment of the Steam community that actually wants to stream their game casts from Linux. And to measure how would this compare to nvidia's nvenc offering.
I celebrate that the people in charge of the project have finally implemented this, so now it would be only a matter of allowing the technology to mature and only get better performance, more robust, improved support for different scenarios and software combinations, etc.
I hope the work from Valve on pushing forward Wayland and keep X11 as a compatibility layer for older software/games will make nVidia shift and start working towards a truly common and universal resource allocation API that will benefit us all (wishful thinking), and that includes them as well, if only for those niches they really care about. Still, I am convinced I will be shifting from team Green back to team Red in the future (haven't used AMD graphics hardware since my ancient R9500 and the nefarious fglrx days)
Quoting: ShmerlI'm somewhat confused, why is it using XWayland unconditionally. XWayland is normally needed only for something that's stuck with X interfaces. Modern games can use SDL or whatever to work with Wayland directly, so that compositor can avoid XWayland for those cases at least?
Many games link directly against X, even 'modern' ones that also use SDL, they won't just go away or be ported.
Run a find+ldd on your steam/games directory to see for yourself.
I last tried Wayland about a year ago, so maybe things have changed:
- Clipboard: no primary selection, because security.
- No input injection to handle such basic use cases as mapping joystick input to keys.
- No input injection to allow you to write macros.
- No key grabbing/global shortcuts (Yeah, I know, keyloggers, but at least give me the option to shoot myself in the foot)
- Screencapture: no.
- Can't query your windows position, which makes proper color management impossible. Because security???
- ...
I personally consider wayland a major regression and am quite thankful to NVidia for holding it back so it doesn't get stuffed down my throat. If that's even the case, it might just be holding itself up.
Waylands seemingly total disregard for practicability and usability means it's not for me.
Last edited by poisond on 17 January 2020 at 10:28 am UTC
Quoting: poisondMany games link directly against X, even 'modern' ones that also use SDL, they won't just go away or be ported.
Run a find+ldd on your steam/games directory to see for yourself.
That's why I said modern games, and I mean native ones. Obviously, you need XWayland for a ton of cases still, especially Wine that still requires X.
As for managing input, there you can use ydotool. Nothing that you mentioned is a regression, but something that should be supported by the compositor. You probably used something poorly developed.
Last edited by Shmerl on 17 January 2020 at 5:54 pm UTC
Patreon
PayPal
See more from me