Support us on Patreon
PayPalWe're getting more and more excited about the Steam Deck, even though Valve has delayed it at least until February 2022 we do now have quite a few more fun details thanks to the recent Steamworks Virtual Conference.
During the event we had a few different people from Valve and AMD talk about quite a lot of things from software to hardware designs and all sorts in between. There we also a number of Q&A sessions where even more details emerged (like Proton or Native Linux?).
Here's a breakdown of some interesting things we now know (click to enlarge any pictures):
SteamOS / Steam UI
- SteamOS 3 is coming but it's not finished as they get it ready for the Steam Deck. Sounds like it won't be readily available to download and run on other systems until after the Steam Deck ships.
- SteamOS will have a read-only immutable main filesystem by default. Updates will be distributed as a whole image and so it will replace it. There will also be a developer mode to let you modify the filesystem.
- Installing external software is an option too. Developer mode is not needed for this, with Flatpak packages getting a clear mention (and "other methods"). They said there's some caveats but they didn't really make it clear what they were meaning.
- New universal search menu that combines results from your library, the store and your friends.
- Dedicated notifications button with a combined list of achievements, messages, downloads etc that's available anywhere.
- New on-screen keyboard has support for IME, multiple languages, layouts and emoji.
- This new SteamOS / Steam Deck UI is far easier for them to maintain and keep parity with the desktop client, so expect much faster and continual updates. Confirmed, again, it will replace Big Picture Mode.
Game Development
- As we wrote about, Valve suggest Manjaro Linux for now to test games but a more developer-focused OS download will be coming with additions like Gamescope and possibly a new gamepad UI.
- Valve are constantly in talks with Unity and Unreal on getting games working well. Additionally, they said they're definitely interested and actively supporting Godot Engine too.
- They confirmed (again?) they do not want developers to make Steam Deck exclusive games, as they see it as a PC.
- Developers can configure content depots on Steam marked as Steam Deck only. So instead of downloading a whole lot of high-resolution textures, developers can set a package of lower resolution textures just for the Deck (as one example).
Hardware
- Dev hardware has issues (as it's just a prototype), which Valve have been solving with the real retail hardware.
- There's a white Portal-themed Steam Deck, which sadly was a prototype that they said they're not able to bring at the same time as the main Steam Deck. However, more colour options are being looked into but that sounds far away.
- They of course did not design it in any way for VR.
- AMD FSR (FidelityFX Super Resolution) will work in games that already support it. A future SteamOS 3 update will include it for games that don't natively support it.
- A spare-parts store sounds like it's being worked on. They said they're "committed to providing as many spare parts after we ship as possible".
- They're "definitely" looking at it like a multi-generational product. This could mean a Steam Deck 2 in future, if it does well enough.
- The USB-C port is capable of 45W, capable of running the Steam Deck at max load while also charge at the full rate. This port also supports external peripherals up to 7.5W enough for webcams, controllers and storage devices and can also be used for docking the Steam Deck to support two 4K displays at 60Hz. You can also opt for half the display bandwidth and get USB 3 gen 2 instead.
- The level of performance-per-watt they've hit would not have been possible with any off the shelf processor that exists today.
- The official name for the AMD Zen 2 chip inside is "Aerith". Here's the diagram they showed off with all the bits inside:
- 1GB of VRAM for the GPU, however the GPU can access up to 8GB depending on what's happening.
Performance
- Storage speeds we already knew were different between models. Valve showed two diagrams that compared game loading performance and the bootup time. For game loading time there was an approximately 12% difference between the top-end model and the 64GB model, and 18% difference between the top model and an SD card. When it comes to boot time, they showed a 25% difference between the top model and the 64GB model.
- Valve picked clock speeds that they can sustain indefinitely so it won't boost up or clock down. They said the performance you see in the first 10 seconds should be the same in 2 hours time and of course the same performance regardless of handheld (battery), charging and docked. They do some extra things when you run out of thermal headroom, with a focus on keeping up GPU performance by throttling other things like charge rates, download speeds and even SSD bandwidth as the system attempts to keep the GPU clock as high as possible.
- There's no artificial limit on how much power the AMD APU can consume, they said they're working on a global FPS limiter to let users pick the balance between performance and battery life.
Steam Cloud
- Steam Cloud is getting an upgrade and will work differently for the Steam Deck. A new feature open to developers will allow them to have a game sync, when it's detected that a user suspends the Steam Deck. When suspending and the feature is ticked by a developer, it will upload any files changed since loading the game. This will make switching between the Steam Deck and another system with Steam on much better.
Steam Input
- A massively reworked interface for Steam Input to adjust your keybinds, with a consistent look across the Steam Deck and main Steam Client. Accessible via mouse/keyboard, touchscreen and gamepads.
- Getting a new set of controller glyphs (icons for A/B/X/Y etc), including those for different types of controller designs (Xbox, PlayStation).
Misc
- Valve are "finalizing" plans to have the Steam Deck available in more countries. Some are ahead of others, it's all about solving logistical issues but they don't have anything to announce right now on it. Still, good news that the problem is being continually worked on. Specifically they said they're working hard on Japan and Australia.
Of course there's a lot more details we missed, as it was hours long but those are some hopefully helpful bits.
They had a few technical troubles with the stream but the majority of it you can watch on YouTube, starting at around 1:04:26 or watch below in our embed:
Direct Link
Ok, it wouldn't say much about playability, but it would at least sort out games that don't start or don't show anything or crash early and the like.
Quoting: EikeI wonder how much a basic test could be automated. Like, starting each Steam game, letting the computer find that a window has been created (or something opened fullscreen), colors have changed, a minute later on pressing a key and/or clicking around with mouse and/or controller buttons, colours change again...I've been curious about that myself. Valve pretty much sits on the biggest collection of Win32 applications in the world, so running regression tests - en masse - on those for new Wine releases would be something.
Ok, it wouldn't say much about playability, but it would at least sort out games that don't start or don't show anything or crash early and the like.
Running tests like it works with the old release but crashes in release +1 and do an automatic bisect until the breakage is found. Or filing automatic bug reports for each failing title and look for patterns: 300+ games crashes with a similar backtrace - that's a bug worth investigating. Or for games that works with GE but not in normal Proton, automatically do a reverse bisect until you find the patch that fixes it and propose that for inclusion in Proton.
I'm not sure why this isn't done. Maybe the amount of "Game crashes on start" issues (which are the easiest to test for) aren't that many?
Quoting: whizseI've been curious about that myself. Valve pretty much sits on the biggest collection of Win32 applications in the world, so running regression tests - en masse - on those for new Wine releases would be something.
Running tests like it works with the old release but crashes in release +1 and do an automatic bisect until the breakage is found. Or filing automatic bug reports for each failing title and look for patterns: 300+ games crashes with a similar backtrace - that's a bug worth investigating. Or for games that works with GE but not in normal Proton, automatically do a reverse bisect until you find the patch that fixes it and propose that for inclusion in Proton.
I'm not sure why this isn't done. Maybe the amount of "Game crashes on start" issues (which are the easiest to test for) aren't that many?
I think you mentioned it yourself why this isn't done:
... the biggest collection of Win32 applications in the world ....
... do an automatic bisect until the breakage is found ...
That's an awful lot of work, you'd probably need a giant cluster to do that in a reasonable amount of time for all of the games/apps.
And you first need to be able to find the faults. While monkey-tests are able to find instabilities in software they usually rely on a certain UI-toolkit. And having games with custom UIs, potentially one that is used by no-one else, doesn't help. To have that tested you'd possibly need hundreds of toolkit to be able to run the tests if you're not only looking for crashes on startup. And you'd also need to test some reasonable input to test normal behaviour. For games that crash only at a specific progress but which is far into the game, you'd possibly need a full playthrough to find that stuff. Which get's us back to the needed ressources. And someone has to write or record all the scripts that need to be replayed for a full walk-through. So the initial amount of work to be done is enormous.
Ergo: The idea is neat but not feasible in a realistic scenario.
Last edited by peta77 on 15 November 2021 at 4:43 pm UTC
Quoting: peta77What's a reasonable time? It doesn't have to be all that fast. Say you have one solid computer sitting around doing that, and it takes 1 minute to launch and test 1 game for 1 Wine version. That's 1440 tests per day. Anything that works with the current version, you don't have to test again until next version comes out, and that's probably like 3/4 of games currently. At first, maybe you have a second solid computer just going through Wine versions for the 1/4 that fail on the first computer. You don't need to go through versions all the way back to 1.0, you just want to do a few to be sure there wasn't a recent regression. And of course you're dumping your results into a database, so second time around you only need to check games once. So with that setup, 1440 games per day, sure that's going to take quite a while to go through all the games . . . but if you go down the list from most towards least popular, by the time the next Wine version comes out and you need to start again, say a month, you've tested the top 43,000 games. That is a really solid chunk of what anyone ever plays.Quoting: whizseI'm not sure why this isn't done. Maybe the amount of "Game crashes on start" issues (which are the easiest to test for) aren't that many?
I think you mentioned it yourself why this isn't done:
... the biggest collection of Win32 applications in the world ....
... do an automatic bisect until the breakage is found ...
That's an awful lot of work, you'd probably need a giant cluster to do that in a reasonable amount of time for all of the games/apps.
Maybe after that first month you can set the second computer continuing down through the lower-popularity games while the first computer keeps looping back to re-test the most popular ones.
I'm sure Steam actively monitors quite a bit of our systems. I know it monitors our game directories (if, say you manually add a mod to a game, it won't let you play it until you upload a copy of it to them or remove it), and it does something with the network (I get a sudo request from Network Manager every time I open Steam - NM is superuser only on my laptop). Even in "offline mode" it reaches out over the network.
We know it tracks whether the game is running, play time, etc. I wouldn't be surprised if it tracks some other info to send to Valve.
Quoting: denyasisBesides, wouldn't it just be easier collect the "does it start?" data from Steam users? Send a lot faster and easier.
I'm sure Steam actively monitors quite a bit of our systems. I know it monitors our game directories (if, say you manually add a mod to a game, it won't let you play it until you upload a copy of it to them or remove it), and it does something with the network (I get a sudo request from Network Manager every time I open Steam - NM is superuser only on my laptop). Even in "offline mode" it reaches out over the network.
We know it tracks whether the game is running, play time, etc. I wouldn't be surprised if it tracks some other info to send to Valve.
We know for sure it tracks play times, so yes, useful data!
Quoting: rustybroomhandleThe read only default mode for the system is understandable. This is why it might be handy to have some utilities installable directly through Steam. Mainly things like Lutris, GOverlay/mangohud, Bottles, ?? If RetroArch can do it, then I see no reason others can not.
Don't forget Luxtorpeda!
See more from me