5 ms·

> Their goal is being able to suspend a game on your desktop and play it on your Deck will likely need them to standardize on a single platform [..] There are

> Their goal is being able to suspend a game on your desktop and play it on your Deck will likely need them to standardize on a single platform [..] There are some additional challenges with this approach [..] but sticking to a single platform [..] removes some concerns with synchronizing lower level state across multiple platforms. My understanding with the suspend/resume stuff they've talked about for the Deck is less about actually suspending/resuming the game by syncing some low-level state like memory or graphics, and more about quickly syncing save games via Steam cloud saves. I only had a quick look over their docs when the Deck was announced and from what I could tell you basically opt into a new system-level save behavior where at any point the Steamworks library can tell the game "this device is going to suspend now, save your progress" then another computer can start the game and immediately load up the save file, giving the impression of seamless suspend/resume. So as long as your save game files aren't OS specific in some way there's no reason why this should lock you into any specific platform, Windows or otherwise.

dathinab 5y ago
Probably that. Anything else also would be insanely hard. Just trying to "store the GPU state" on a system with AMD GPU and resume it on a system with a NVIDIA GPU (or just old GPU and new GPU from same Vendor) is likely around the area of "lets treat it as impossible".
- davesque 5y ago
  Almost impossible and also rather impractical. What each game should care about are the high level details of its game state. Things like "In what map am I located and at what coordinates?" The game engine for each game basically represents a compression algorithm of sorts to decode the meaning of a few concise details like that. If you prefer to represent that information with the raw bytes and bits of internal processor and memory state, you're choosing a hugely inefficient and clunky encoding.
  - eropple 5y ago
    You're assuming a lot of things in the pursuit of a perfectly spherical game, here. If it were that simple, one might think developers would already do similar. And some do. But a lot of games have issues with this approach, particularly when negotiating data that is partially owned by the engine and that which is owned by game logic.
  - mmis1000 5y ago
    In reality, make game state transferable takes huge efforts. When you are writing a program, there are a lot of states, some of them are visible to code, some of them are not, some of them are about game logic, some of them are tight to machine physical states. And you are almost not going to separate them unless specifically designed it to. And that is called save system. But the problem of save system is: that is slow to load, because you need to initialize everything from ground up. All the textures, stage data, enemy entities will need to be reloaded even it is technically fine to reuse all of them. And that is what xbox do(I think steam is unlikely to copy that?) The idea of quick resume is to sacrifice storage spaces, just store everything(even things tight to hardware) to skip the initialization process for fast loading, which is completely opposite for what steam want to do. Until now, only xbox implemented that (on same machine only)
    - vlovich123 5y ago
      You’re talking about transferring many GBs of video textures and other GPU state between GPU vendors. Even across a USB3.0 interface this seems slower and an order of magnitude more difficult than just providing a mechanism to manage the save state more effectively. Look at the stuff PS5 and UE5 are doing with instant high res loading instantaneously. These are more tractable problems (in the past games like HL, which was written by Valve, show that it’s possible to have seamless instantaneous loading)
    - dathinab 5y ago
      For quick resume on the same device, assuming no OS update was done, dumping memory might work. But I just can't see it working across OSes. Maybe if you limited it to same ARCH (or even vendor, AMD here) and dump everything but use some tricks wrt. GPU state? (And also not dumping OS discardeable caches, no idea if that is used by games though).
- philo23 5y ago
  Yeah exactly, it's probably impossible even between different generations of the same brand of graphics card.
- rektide 5y ago
  > Anything else also would be insanely hard. checkpoint restore of gpu state is much further along than you credit.
  - account42 5y ago
    GPU is just one part, there are many more. As soon as you have network connections in play the state you'd need to restore isn't even all on the device.
  - LadyCailin 5y ago
    You mean for the same GPU? Or across GPU brands and stuff?
    - namibj 5y ago
      Even the latter, as long as you're doing something like restricting yourself to a shared subset of OpenGL. You really just need to dump textures and set up a matching context, which at worst should require an indirection shim to translate handles if they are stored by the application but generated by the driver with no way to force custom values during object creation (like how Linux allows custom PIDs for checkpoint/restore and other replay tech like rr).
      - Hello71 5y ago
        rr doesn't need or use checkpoint/restore functionality. it's insufficient because rr already needs to catch and emulate all syscalls made by a process, and unnecessary because once you're doing that it's (relatively) easy to also emulate getpid. it also requires CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE.
      - account42 5y ago
        "a matching context" means having exactly the same handles for all objects (since application memory will have references to them) and with modern-enough OpenGL even means having the same (virtual) memory addresses for all GPU-side buffers as well as the same addresses for any host-side mappings. This is probably not something you could build on top of OpenGL or even on top of the existing kernel-side drivers. Even if have a perfect wrapper that achieves all that you now have to save all application-supplied texture and shader data in the original form even where that memory could normally be freed after translating it to GPU-specific formats. But "restricting yourself to a shared subset of OpenGL" alone already makes this unviable for anything demanding as it also means restricting yourself to the lowest common denominator for all limits including VRAM size, maximum texture sizes, essentially guaranteeing your solution to run worse on both systems.
- jorvi 5y ago
  Wouldn’t this be very possible with an Intermediate Representation?
initplus 5y ago
Perhaps I've misunderstood but my understanding was that suspend/resume on the deck itself is recording some low level state (locally). So you can reopen the deck and be right where you left off with no loading. But they also provide a hook so the game has a chance to save and sync to the cloud before being suspended, so the user can pick up from the same point on another steam device. Loading the game normally of course.

dathinab 5y ago

Probably that. Anything else also would be insanely hard. Just trying to "store the GPU state" on a system with AMD GPU and resume it on a system with a NVIDIA GPU (or just old GPU and new GPU from same Vendor) is likely around the area of "lets treat it as impossible".

davesque 5y ago
Almost impossible and also rather impractical. What each game should care about are the high level details of its game state. Things like "In what map am I located and at what coordinates?" The game engine for each game basically represents a compression algorithm of sorts to decode the meaning of a few concise details like that. If you prefer to represent that information with the raw bytes and bits of internal processor and memory state, you're choosing a hugely inefficient and clunky encoding.
- eropple 5y ago
  You're assuming a lot of things in the pursuit of a perfectly spherical game, here. If it were that simple, one might think developers would already do similar. And some do. But a lot of games have issues with this approach, particularly when negotiating data that is partially owned by the engine and that which is owned by game logic.
- mmis1000 5y ago
  In reality, make game state transferable takes huge efforts. When you are writing a program, there are a lot of states, some of them are visible to code, some of them are not, some of them are about game logic, some of them are tight to machine physical states. And you are almost not going to separate them unless specifically designed it to. And that is called save system. But the problem of save system is: that is slow to load, because you need to initialize everything from ground up. All the textures, stage data, enemy entities will need to be reloaded even it is technically fine to reuse all of them. And that is what xbox do(I think steam is unlikely to copy that?) The idea of quick resume is to sacrifice storage spaces, just store everything(even things tight to hardware) to skip the initialization process for fast loading, which is completely opposite for what steam want to do. Until now, only xbox implemented that (on same machine only)
  - vlovich123 5y ago
    You’re talking about transferring many GBs of video textures and other GPU state between GPU vendors. Even across a USB3.0 interface this seems slower and an order of magnitude more difficult than just providing a mechanism to manage the save state more effectively. Look at the stuff PS5 and UE5 are doing with instant high res loading instantaneously. These are more tractable problems (in the past games like HL, which was written by Valve, show that it’s possible to have seamless instantaneous loading)
  - dathinab 5y ago
    For quick resume on the same device, assuming no OS update was done, dumping memory might work. But I just can't see it working across OSes. Maybe if you limited it to same ARCH (or even vendor, AMD here) and dump everything but use some tricks wrt. GPU state? (And also not dumping OS discardeable caches, no idea if that is used by games though).
philo23 5y ago
Yeah exactly, it's probably impossible even between different generations of the same brand of graphics card.
rektide 5y ago
> Anything else also would be insanely hard. checkpoint restore of gpu state is much further along than you credit.
- account42 5y ago
  GPU is just one part, there are many more. As soon as you have network connections in play the state you'd need to restore isn't even all on the device.
- LadyCailin 5y ago
  You mean for the same GPU? Or across GPU brands and stuff?
  - namibj 5y ago
    Even the latter, as long as you're doing something like restricting yourself to a shared subset of OpenGL. You really just need to dump textures and set up a matching context, which at worst should require an indirection shim to translate handles if they are stored by the application but generated by the driver with no way to force custom values during object creation (like how Linux allows custom PIDs for checkpoint/restore and other replay tech like rr).
    - Hello71 5y ago
      rr doesn't need or use checkpoint/restore functionality. it's insufficient because rr already needs to catch and emulate all syscalls made by a process, and unnecessary because once you're doing that it's (relatively) easy to also emulate getpid. it also requires CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE.
    - account42 5y ago
      "a matching context" means having exactly the same handles for all objects (since application memory will have references to them) and with modern-enough OpenGL even means having the same (virtual) memory addresses for all GPU-side buffers as well as the same addresses for any host-side mappings. This is probably not something you could build on top of OpenGL or even on top of the existing kernel-side drivers. Even if have a perfect wrapper that achieves all that you now have to save all application-supplied texture and shader data in the original form even where that memory could normally be freed after translating it to GPU-specific formats. But "restricting yourself to a shared subset of OpenGL" alone already makes this unviable for anything demanding as it also means restricting yourself to the lowest common denominator for all limits including VRAM size, maximum texture sizes, essentially guaranteeing your solution to run worse on both systems.
jorvi 5y ago
Wouldn’t this be very possible with an Intermediate Representation?

initplus 5y ago

Perhaps I've misunderstood but my understanding was that suspend/resume on the deck itself is recording some low level state (locally). So you can reopen the deck and be right where you left off with no loading. But they also provide a hook so the game has a chance to save and sync to the cloud before being suspended, so the user can pick up from the same point on another steam device. Loading the game normally of course.