Skip to content
Snippets Groups Projects
  1. May 11, 2021
  2. May 07, 2021
  3. Apr 30, 2021
    • Simon McVittie's avatar
      runtime: Add support for creating runtime from a mtree(5) · 799b7931
      Simon McVittie authored
      
      At the moment we deploy the runtime from a giant tarball to avoid Steam
      downloader limitations, but that leads to a noticeable delay the first
      time we launch a game after a new runtime version has been downloaded.
      
      Now that the Steam download mechanism can deal better with larger
      numbers of smaller files, we're considering returning to the original
      design where the runtime depot contains unpacked files. However, the
      Steam download mechanism doesn't preserve permissions, modification
      times, or filenames that differ only by case, and has not always
      preserved empty directories, so we need a way to deal with all of
      those things.
      
      By reading a manifest written in a subset of the BSD mtree(5) format,
      we can create directories and symlinks, and set permissions modification
      times on regular files. As a bonus, it's actually slightly faster to
      duplicate a runtime with hard-links (--copy-runtime mode) by reading the
      manifest than by reading the actual directory tree, because the manifest
      is more likely to be contiguous on disk.
      
      In principle the mtree(5) manifest could also be used to validate that
      the runtime content has not become corrupted by checking files against
      their sha256sums. This isn't implemented here (and it would have to be
      done only on demand rather than routinely, because it would be slow),
      but the parser does at least read the sha256.
      
      In the tests, we now need to remove the mtree manifest when copying
      and editing a runtime. When we edit a runtime in-place, it no longer
      conforms to the manifest, so this can't necesarily be expected to work.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      799b7931
  4. Apr 28, 2021
  5. 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
    • Ludovico de Nittis's avatar
      runtime: Avoid Wayland when in a Scout container · b11ba4cc
      Ludovico de Nittis authored
      
      Unset SDL_VIDEODRIVER if it was previously set to "wayland", when we are
      in a Scout SteamLinuxRuntime, because Scout is too old to support
      Wayland.
      
      This is not necessary for Soldier or Sniper because we expect it to be
      working for them.
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      b11ba4cc
  6. Apr 26, 2021
  7. Apr 22, 2021
  8. Apr 21, 2021
  9. Apr 20, 2021
  10. Apr 16, 2021
  11. Apr 13, 2021
  12. Apr 09, 2021
  13. Mar 17, 2021
  14. Mar 16, 2021
    • Ludovico de Nittis's avatar
      runtime: Create library aliases in overrides · 39a0cacd
      Ludovico de Nittis authored
      If a library has different SONAMEs, called aliases in
      "steam-runtime-abi.json", it might lead to errors when a game tries to
      load a SONAME that is not the "real" library SONAME (the DT_SONAME that
      objdump shows). Because `ld.so.cache` will not consider the aliases when
      searching for the right match.
      
      To workaround this problem we create a directory called "aliases" that
      contains symlinks of the libraries aliases that we know about.
      
      By adding these directories, one for every multiarch, in the
      `LD_LIBRARY_PATH`, we ensure that even games that were linked to an
      alias will be able to find the library they were looking for.
      
      Helps: https://github.com/ValveSoftware/steam-runtime/issues/246
      
      
      Fixes: T26816
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      39a0cacd
  15. Mar 04, 2021
  16. Mar 03, 2021
  17. Feb 26, 2021
Loading