The Steam Deck Conference: Key Takeaways

By

The Steam Deck conference has just finished this Friday (US time), and though the conference suffered from technical difficulties five minutes into the stream, Valve did a pretty good job to cover a lot of ground in a very short time. They later added the recording to YouTube. I also like the fact they do not indulge in marketing/PR bullshit in these kind of presentations, and rather focus on design/technical aspect. You can read further documentation on the Steam Deck in the Steamworks documentation.

Here’s a few things we wanted to highlight after watching the video. We will review the key take-aways bullet-point style, with a few inline comments.

Steam Deck Hardware Design

  • Here’s the Steam Deck hardware overflow:

Steck deck hardware chart

  • LPDDR5 was chosen as the RAM for power efficiency and larger bandwidth memory speeds (the Deck is also one of the first devices on the market to use this class of RAM)
  • 16 GB RAM was chosen because even though many games today only consume 8-12 GB, the extra RAM will come in handy for games that come in the future. The whole RAM is unified between the CPU and integrated GPU, and 1 GB is reserved for the GPU. The GPU can allocate more depending on what’s being played (up to 8 GB).
  • Deck storage speeds were compared between different models (Games take a little longer to load with eMMC and SD card, the SD card being the slowest at 18% slower. The Deck takes 25% longer to boot on eMMC than the NVMe models), and the overall message from Valve is that no matter the storage used, games will load very fast anyway:

Storage medium speed chart

  • Bluetooth (uses 5.0) should have more than enough bandwidth to have controllers and audio at the same time
  • Performance is intended to be the same regardless of whether the Deck is docked, undocked, charging, or not charging: this is pretty neat, and better than hardware like the Switch in that regard.
  • Wi-Fi uses 802.11ac and has a maximum bandwidth speed of 866 Mbps
  • Valve is going to setup a spare parts store, but they have no details to share at this time
  • Multi generations of Deck were confirmed (that was already kind of obvious but nice to hear it again)
  • Only one color so far, but there will be other colors available at some point in the future.

Developing for the Steam Deck

  • The Deck will use Wayland by default
  • Manjaro KDE is recommended as the distro to test your games with in the event you can’t get a dev kit (Valve can’t keep up with demand). Valve also recommends getting an AMD NUC box that has similar hardware as the Deck (Ryzen 7 3750H, Radeon RX Vega 10 Graphics, 16GB of DDR4 RAM) and a small 720p monitor to boot. They mentioned that it’s probably a bit better than the Deck when it comes to the CPU power, but a little weaker on the GPU side. It looks ETA Prime has reviewed this kind of hardware earlier this year and did a couple of benchmarks on Windows.

Hackendeck

  • VMs for testing are not recommended as it will be difficult to get GPU performance out of it, but it could be good to confirm how menus look like for example.
  • Implementing a 60 or 30 FPS limiter for games is recommended to conserve as much battery as possible. If a dev can’t provide this, Valve is working on their own solution that can be used globally across multiple games
  • Game devs are encouraged to make sure the suspend feature works as intended, but Valve said this isn’t really something to worry about as most of the games they tested work without issue
  • Assets repositories: Valve will have an option to store assets made for the Steam Deck (such as lower resolution textures) to ensure that games downloaded for the Deck don’t take 100 gigs (most of the space is wasted on 4K textures that would not be used). This is just a recommendation and it does not seem to be enforced in any way. Let me say I’d vote for that, and not just for the Deck but for all games on Steam. I don’t want to fill my HDD with game assets for resolutions I never used.
  • Gyro can be used by putting pressure on one of the thumbsticks, but this can of course be customized
  • The Deck will use the Steam Input API to make devs’ lives easier for in-game button prompts (i.e. “jump” button rather than “A” or “Cross”)
  • Button glyphs will be provided for devs to match the same button style as on the Deck.
  • The use of launchers is discouraged, but Pierre-Loup Griffais said implementing a Qt-based launcher should be recommended if you need a launcher. The use of anti-cheat software and Media Foundation playback is also not recommended, as this would require additional work with the anti-cheat vendor - as for media files, using open formats instead of WMF is the way to go.
  • If possible, Vulkan is recommended to use as a backend, since OpenGL/DirectX uses more CPU overhead and therefore consumes more battery life. It would be a good idea to enable Vulkan backends in Windows versions of the games from now on, if the engine allows it.
  • Valve has no particular preference whether a dev makes their game Proton-compatible or native to Linux.
  • AMD is preparing a native Linux profiler to observe the bottlenecks in performance in your application between CPU and GPU.
  • DX12 recommended over DX11 on the Deck: it seems like the VKD3D translation layer from DX12 to Vulkan has become so good that performance should be better than using DX11 with DXVK. We think this may be a very specific recommendation for the Deck hardware and its drivers (AMD + Mesa) and probably not valid for all configurations out there on Linux.
  • Valve is working with multiple engine developers to roll out support, with Unity, Unreal and Godot Engine too.
  • The Deck uses Xinput
  • Many tools for testing and profiling will be provided by Valve as we get closer to the launch date (and after too).

SteamOS

  • SteamOS is based on Arch, but has an immutable file system, with a specific developer mode to unlock the FileSystem if needed. Similar to ChimeraOS (or ChromeOS) approach. You should be able to install applications through flatpaks and not normal packages, so the way to modify might be somewhat limited. There should be also more ways to add packages but they did not expand on that.
  • SteamOS 3 will be released after the Deck.
  • New Big Picture Mode will also be released after the Deck.
  • The New Big Picture Mode also has a new controller setup screen that looks quite different from what you are used to. See below:

Other Aspects

  • Japan is coming (Australia too). Which is great for Eki!
  • There won’t be any Steam Deck-exclusive games.
  • Asked multiple times: Valve will make it easy to install non-steam games too. So you will be able to side-load other stores and emulators just as planned.
  • You can do VR on the Deck but the hardware is certainly not made for that at all.

Conclusion

Many new details, and a lot of Q&A to confirm several aspects that we did not know much about until now. My greatest dissapointment is that there was no mention of the dock (unless I missed it), which is a missed opportunity as I would have really like to see what they have planned and how well and usable the Deck is a desktop computer in an actual demo. Other than that, all news were pretty much good news and indicated that Valve has really thought well about numerous aspects of the device, be it hardware, software, and the integration of both. Really looking forward to having one in my hands.

While this article is published under my name, this summary could not have been completed without the help of cow_killer, Podiki and Patola - thanks guys for watching everything and capturing most relevant points!