Skip to content
Snippets Groups Projects
  1. Aug 06, 2021
  2. Aug 03, 2021
  3. May 07, 2021
  4. Apr 27, 2021
    • 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 13, 2021
  6. Mar 17, 2021
  7. Mar 03, 2021
  8. Feb 26, 2021
  9. Feb 23, 2021
  10. Feb 22, 2021
  11. Feb 04, 2021
    • Simon McVittie's avatar
      pressure-vessel: Accept runtime with or without ./files · 5570e4a8
      Simon McVittie authored
      
      Previously, if we were using a Flatpak-style runtime, the argument
      to --runtime= had to be its ./files subdirectory. Now we accept the
      top-level directory as an alternative.
      
      This will make it more straightforward for pressure-vessel-wrap to
      take responsibility for unpacking and deploying runtimes that are
      shipped as a tarball, which is currently done in the SteamLinuxRuntime
      shell scripts, resulting in error handling and locking being less
      robust.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      5570e4a8
  12. Jan 05, 2021
  13. Dec 09, 2020
    • Simon McVittie's avatar
      pressure-vessel: Make graphics drivers outside $HOME available, if used · 23834972
      Simon McVittie authored
      Since !173, we have been able to create symbolic links to graphics
      drivers anywhere on the filesystem, but that didn't mean the graphics
      driver would necessarily be usable, because the directory containing it
      would not necessarily be visible in the container. Add these directories
      to the list of directories to be "exported".
      
      Manual test (Debian on on Intel hardware, adjust as required for
      others):
      
      * Modify /usr/share/vulkan/icd.d/intel_icd.i686.json
        to use /opt/moved-from-usr/lib/i386-linux-gnu/libvulkan_intel.so
      * Move the real i386 libvulkan_intel.so to that location
      * ./run --verbose -- steam-runtime-system-info 2>&1 | tee container.log
      
      Resolves: #29
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/313
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23834972
  14. Nov 30, 2020
  15. Oct 26, 2020
  16. Oct 01, 2020
  17. Sep 25, 2020
  18. Sep 09, 2020
  19. Sep 02, 2020
    • Ludovico de Nittis's avatar
      Initial support for custom graphics provider path and Flatpak · d7ad67a2
      Ludovico de Nittis authored
      
      pressure-vessel had a few hard coded assumptions about the host system
      and where to look at for the graphics provider.
      
      For example it was assumed that the root was the same host system used
      by both pressure-vessel current environment (where pressure-vessel-wrap
      runs) and also later on by `bwrap`.
      
      But when we run pressure-vessel in a Flatpak container, the final
      `bwrap` command is expected to be executed against the real host system
      (mounted in `/run/host`, in Flatpak).
      
      Also when we are in a Flatpak container we might want to pick the
      graphics stack from the host system (`/run/host`), from the Flatpak
      container itself or it could even be a completely separate one.
      (T22373, T22371)
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      d7ad67a2
  20. Aug 18, 2020
    • Simon McVittie's avatar
      adverb, wrap: Add --terminate-timeout, --terminate-idle-timeout options · 18bdc4b9
      Simon McVittie authored
      
      This will let us have the following logic when sharing a container
      between multiple commands using -launcher and -launch:
      
      * For setup commands, don't wrap the launched command in the adverb.
        If the setup command starts background processes, they'll continue
        to run. This matches how installscript commands have historically
        worked for Windows (and Wine/Proton) games in Steam: the setup
        command is launched with system(), and can leak background
        processes like wineserver.
      
      * For the main game, wait for all processes to exit, by wrapping
        the launched command in the adverb, with --subreaper only. This
        matches how native Linux games, and the main command of
        Windows/Wine/Proton games, have historically worked in Steam.
      
      * When all processes belonging to the main game have exited,
        the -launcher can exit, at which point the subreaper that wraps it
        can clean up any background processes from the setup commands.
      
      --terminate-idle-timeout can be used to wait a few seconds before
      sending SIGTERM, if desired.
      
      Because the adverb now blocks SIGCHLD, we need to unblock it before
      running the child process; otherwise the child process will inherit
      the blocked signal, breaking things like g_spawn_async().
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      18bdc4b9
  21. Jul 29, 2020
  22. Jul 21, 2020
  23. Jun 17, 2020
  24. Jun 12, 2020
  25. Mar 04, 2020
Loading