Announcement

Collapse
No announcement yet.

Fossilize Is Valve's Latest Open-Source Vulkan Project

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fossilize Is Valve's Latest Open-Source Vulkan Project

    Phoronix: Fossilize Is Valve's Latest Open-Source Vulkan Project

    Valve Software has been backing work on Fossilize as an open-source project providing a serialization format for persistent Vulkan object types...

    http://www.phoronix.com/scan.php?pag...ssilize-Vulkan

  • #2
    Serialization of objects and render without having to run the application itself. Smells like groundwork for a protocol. Dare I guess for the purpose of supporting thin clients down the road and maybe something in the direction of Stadia.

    Comment


    • #3
      Originally posted by zoomblab View Post
      supporting thin clients down the road
      I'm reading this more like storing the stuff before it gets rendered. The replay portion is replaying vulkan commands through a GPU.

      You could perhaps create a fat client, where the software remains on their server and it's just your computer rendering the output, but unless they're really trying to push the subscription model, this only helps with a little bit of piracy. I'm not sure it would offset the server-side costs and latency issues.

      I think this has more value for quick screen-capture, heuristic anti-cheat (like an overwatch crowd-sourced replay maybe), speed up the loading of savegames?

      Comment


      • #4
        Originally posted by oliw View Post
        I'm reading this more like storing the stuff before it gets rendered. The replay portion is replaying vulkan commands through a GPU.
        Not entirely wrong but the main focus here would be shaders and pipelines. Those are shipped in source-format to support all known and future unknown GPUs, optimizing compilers will typically be run the first time you start the game and they will end up in a cache for reuse (aslong as you dont swap your GPU/Drivers).
        This is primary for storing/restoring internal setup state, not to replay rendering steps.

        Originally posted by oliw View Post
        You could perhaps create a fat client, where the software remains on their server and it's just your computer rendering the output, but unless they're really trying to push the subscription model, this only helps with a little bit of piracy. I'm not sure it would offset the server-side costs and latency issues.
        If you mean sending over rendering steps, this would scale horribly. The client would have to be smart to take over some work, at which point you would have to lock-down your game-engine.
        ie. this has been done for ages with d3d10+ games, just the format is AFAIK just a unspecified blob thats OS and GPU(-Driver) specific. A common format would allow the cache to be prepared and shipped.

        If I had to come up with some usecases outside of those (already existing shader-cache like scenarios), you could let a game export a render setup, and resources (textures, soundeffects) perhaps some simple serialized formulas to animate a couple objects and have a launcher display some (simple) scenes from the game.
        (The later parts would be the game and rendering logic steps/mechanisms that are not covered by the project at all).

        Comment


        • #5
          Originally posted by discordian View Post
          Not entirely wrong but the main focus here would be shaders and pipelines. Those are shipped in source-format to support all known and future unknown GPUs, optimizing compilers will typically be run the first time you start the game and they will end up in a cache for reuse (aslong as you dont swap your GPU/Drivers).
          This is primary for storing/restoring internal setup state, not to replay rendering steps.


          If you mean sending over rendering steps, this would scale horribly. The client would have to be smart to take over some work, at which point you would have to lock-down your game-engine.
          ie. this has been done for ages with d3d10+ games, just the format is AFAIK just a unspecified blob thats OS and GPU(-Driver) specific. A common format would allow the cache to be prepared and shipped.

          If I had to come up with some usecases outside of those (already existing shader-cache link scenarios), you could let a game export a render setup, and resources (textures, soundeffects) perhaps some simple serialized formulas to animate a couple objects and have a launcher display some (simple) scenes from the game.
          (The later parts would be the game and rendering logic steps/mechanisms that are not covered by the project at all).
          You could perhaps create a fat client, where the software remains on their server and it's just your computer rendering the output, but unless they're really trying to push the subscription model, this only helps with a little bit of piracy. I'm not sure it would offset the server-side costs and latency issues.

          Comment

          Working...
          X