Skip to content
Snippets Groups Projects
  1. Jun 08, 2021
    • Simon McVittie's avatar
      CI: Add infrastructure to upload pressure-vessel releases · dbed11b8
      Simon McVittie authored
      
      When combined with changes to SteamLinuxRuntime scripts, this will let
      us do a new pressure-vessel release and incorporate it into
      soldier/sniper/etc. depots, without having to do a whole release of
      scout to provide the new pressure-vessel.
      
      These releases don't include anything that we didn't already publish
      in Gitlab artifacts, and they're relatively small, so they might as well
      be public immediately (unlike the full scout releases, which we avoid
      publishing before they are final, both because they are rather large and
      because game developers could get compatibility issues if they build
      against a non-finalized scout runtime).
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      dbed11b8
  2. Jun 07, 2021
  3. May 25, 2021
  4. May 20, 2021
  5. May 17, 2021
  6. May 12, 2021
  7. May 11, 2021
  8. May 07, 2021
  9. 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
    • Simon McVittie's avatar
      pressure-vessel: Add code to parse and apply a mtree(5) manifest · 1bdf777d
      Simon McVittie authored
      
      This can be used to create directories, symlinks and zero-byte files,
      create files as a clone (hard-link or copy) of files in a reference
      directory, assert that files exist, set executable/non-executable
      permissions, and set files' modification times.
      
      When cloning files from a reference directory, the default is to use
      the same filename as the destination, but that can be overridden
      (for example to deal with inconvenient/non-Windows-friendly filenames).
      This is also actually slightly faster than pv_cheap_tree_copy(),
      presumably because the manifest is contiguous on-disk and the
      directories are not necessarily.
      
      Setting directories' modification times is implemented, but probably
      won't work in practice, because any files we create in the directory
      will alter its mtime.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1bdf777d
  10. Apr 28, 2021
  11. 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
    • 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
  12. Apr 26, 2021
  13. Apr 22, 2021
  14. Apr 21, 2021
  15. Apr 20, 2021
  16. Apr 19, 2021
  17. Apr 16, 2021
Loading