Skip to content
Snippets Groups Projects
  1. May 25, 2021
  2. May 12, 2021
  3. May 07, 2021
  4. Apr 27, 2021
    • Simon McVittie's avatar
      pv-wrap: Measure total PvRuntime setup time · 1ac3b2d8
      Simon McVittie authored
      
      This is helpful when trying to reduce this time by parallelizing.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1ac3b2d8
    • Simon McVittie's avatar
      pv-runtime: Use threads to enumerate graphics drivers in parallel · 94699abd
      Simon McVittie authored
      
      SrtSystemInfo is not thread-aware, but can safely be handed off from
      one thread to another, and caches its results internally; so we can use
      a thread per architecture, plus an extra thread for cross-architecture
      Vulkan and EGL ICDs, to enumerate graphics drivers and populate the
      cache in parallel with any other container setup. We join the threads
      just before looking at their results, to maximize the length of time
      for which we're running in parallel.
      
      On slow hardware (Lenovo T520 circa 2011, with 500G 7200rpm HDD) this
      cuts something like 20% off the setup time with a cold cache
      (`echo 3 | sudo tee /proc/sys/vm/drop_caches`). It also has a benefit
      (more like 15%) with a warm cache, immediately after a previous
      pressure-vessel run.
      
      This does make it somewhat harder to profile pressure-vessel, because
      when two I/O-bound operations run in parallel, they both take longer
      than they otherwise would, even though the overall task finishes sooner;
      this makes it hard to attribute I/O cost to particular actions. The
      new --single-thread option can be used to get a better idea of where
      the time is really going.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      94699abd
    • Simon McVittie's avatar
      pv-runtime: Convert the graphics provider into an object · 98ac00a1
      Simon McVittie authored
      
      This encapsulates both the PROVIDER_GRAPHICS_STACK flag and the
      associated paths: if the object is null then the paths are meaningless,
      and if the object is non-null then they are meaningful.
      
      Making this an immutable "value object" also means we can share it
      between threads, unlike PvRuntime, which has state. This could become
      important if we want to make graphics driver enumeration multi-threaded
      to speed up pressure-vessel.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      98ac00a1
  5. Apr 16, 2021
    • Simon McVittie's avatar
      pv-wrap: Remove support for escaping from a Flatpak container · f4f25f4b
      Simon McVittie authored
      
      We did this as a very early prototype, but it never fully worked, and
      required configuring Flatpak specially to allow Steam to escape from the
      sandbox (which obviously undermines Flatpak's intended sandboxing).
      
      Now that we've implemented the features we need in Flatpak's
      sub-sandboxing code, we have a better way to handle this, and can
      simplify the code by not trying to have it both ways.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      f4f25f4b
  6. Apr 14, 2021
  7. Apr 13, 2021
  8. Apr 06, 2021
  9. Mar 23, 2021
    • Ludovico de Nittis's avatar
      wrap: Use a tmpfs home as a fallback when unsharing the home dir · 604e3531
      Ludovico de Nittis authored
      
      If we don't want to share the host home directory we expect to have
      either --home, --freedesktop-app-id, --steam-app-id or $SteamAppId.
      
      There are cases where this might not happen. For example if Steam has
      been launched with the PRESSURE_VESSEL_SHARE_HOME=0 env variable and we
      try to run "Help->System Information", the variable $SteamAppId will not
      be set and the container creation will fail.
      
      To avoid this issue we can use a tmpfs for the home directory when we
      are in batch mode.
      In this way the tmpfs will not be used if we need to run an actual game,
      because we want to retain the home directory on exit.
      
      Fixes: #66
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      604e3531
  10. Mar 17, 2021
  11. Mar 16, 2021
  12. Mar 12, 2021
    • Simon McVittie's avatar
      wrap: Put game-specific $HOME on bwrap command-line before exports · 242e8906
      Simon McVittie authored
      This is how Flatpak behaves, and it's necessary to prevent the
      game-specific $HOME from being mounted over the top of some of the
      exports, preventing (for example) ~/.steam from being exposed to the
      container.
      
      We only do this for $HOME rather than completely reverting 3a8e939d,
      so that it won't be a regression for a symlink at /var/tmp.
      
      If the logical and physical paths to the real $HOME differ, we now also
      mount the game-specific $HOME onto the real $HOME's physical path, and
      replicate the logical path's symlinks in the container. This matches how
      Flatpak works, and avoids a similar regression.
      
      Fixes: 3a8e939d "pv-wrap: Delay --dir, etc. until after FlatpakExports are processed"
      Resolves: #63
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      242e8906
  13. Mar 03, 2021
  14. Mar 01, 2021
  15. Feb 26, 2021
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      pressure-vessel: Add experimental code path for Flatpak sub-sandboxing · 1e7e83c9
      Simon McVittie authored
      
      This is experimental and subject to change. It requires branches of
      Flatpak that have not yet been reviewed or merged, so it's guarded
      by (deliberately undocumented) environment variables by default.
      Only enable this if you are a pressure-vessel developer and know
      precisely what you're doing.
      
      This feature also requires a non-setuid bwrap executable, and a kernel
      that allows the non-setuid bwrap to create new user namespaces.
      Fedora, Ubuntu, Debian >= 11, and Arch Linux's default kernel are
      examples of systems that should be OK; Debian <= 10, SteamOS 2, and
      Arch Linux's linux-hardened are not.
      
      I'm landing this despite its experimental status because leaving it in
      a branch means we have to rebase it all the time, which just slows
      us down.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1e7e83c9
    • Simon McVittie's avatar
      pv-wrap: Delay --dir, etc. until after FlatpakExports are processed · 3a8e939d
      Simon McVittie authored
      If the FlatpakExports has set these up to be symlinks, it's harmless
      to use --dir redundantly; but if we do these too soon, the
      FlatpakExports would be unable to create its symlinks and would fail.
      
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/368
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      3a8e939d
    • Simon McVittie's avatar
      474280b2
    • Simon McVittie's avatar
      pressure-vessel: Put apt-style severity prefixes on messages · dbf21961
      Simon McVittie authored
      
      These indicate which lines are harmless and which lines are really bad,
      without taking up too much space.
      
      The mapping from GLib log level to message is not 100% obvious, because
      G_LOG_LEVEL_ERROR is "worse than" an error. We diagnose "can't happen"
      situations (assertion failures, etc.) as "Internal error". Ideally,
      users should never see these: they indicate a bug.
      
      For situations that will cause pressure-vessel to exit with an error,
      introduce a new log level flag PV_LOG_LEVEL_FAILURE and map it to the
      apt-style "E:" prefix. pv_log_failure() is a convenience macro to log
      at level PV_LOG_LEVEL_FAILURE. Conceptually this is a fatal error, but
      it's a fatal error prompted by something external to pressure-vessel,
      for which we want pressure-vessel to clean up "nicely" and exit
      gracefully, even though it's going to fail - so we can't use g_error()
      for this.
      
      In the parts of main() that involve parsing command-line arguments,
      add usage_error() as syntactic sugar for pv_log_failure(). I might
      eventually turn these into G_OPTION_ERROR_FAILED as we factor out
      more of main() into helper functions, but for now they're handled
      separately.
      
      For less-severe log levels, use single-letter prefixes similar to apt's.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      dbf21961
  16. Feb 25, 2021
  17. Feb 24, 2021
  18. Feb 23, 2021
  19. Feb 22, 2021
Loading