Coder Social home page Coder Social logo

fossilize's Introduction

Fossilize

Build Status

Fossilize is a library and Vulkan layer for serializing various persistent Vulkan objects which typically end up in hashmaps. CreateInfo structs for these Vulkan objects can be recorded and replayed.

  • VkSampler (immutable samplers in set layouts)
  • VkDescriptorSetLayout
  • VkPipelineLayout
  • VkRenderPass
  • VkShaderModule
  • VkPipeline (compute/graphics)

The goal for this project is to cover some main use cases:

  • For internal engine use. Extend the notion of VkPipelineCache to also include these persistent objects, so they can be automatically created in load time rather than manually declaring everything up front. Ideally, this serialized cache could be shipped, and applications can assume all persistent objects are already created.
  • Create a Vulkan layer which can capture this cache for repro purposes when errors occur before we can create a conventional capture.
  • Serialize state in application once, replay on N devices to build up VkPipelineCache objects without having to run application.

Build

Supported compilers

  • GCC 4.8+
  • Clang
  • MSVC 2013/2015/2017+

If rapidjson is not already bundled in your project, you need to check out the submodules.

git submodule update --init

otherwise, you can set FOSSILIZE_RAPIDJSON_INCLUDE_PATH if building this library as part of your project. It is also possible to use FOSSILIZE_VULKAN_INCLUDE_PATH to override Vulkan header include paths.

Normally, the CLI tools will be built. These require SPIRV-Tools and SPIRV-Cross submodules to be initialized, however, if you're only building Fossilize as a library/layer, you can use CMake options -DFOSSILIZE_CLI=OFF and -DFOSSILIZE_TESTS=OFF to disable all those requirements for submodules (assuming you have custom include path for rapidjson). Standalone build:

mkdir build
cd build
cmake ..
cmake --build .

Link as part of other project:

add_subdirectory(fossilize EXCLUDE_FROM_ALL)
target_link_library(your-target fossilize)

For Android, you can use the android_build.sh script. It builds the layer for armeabi-v7a and arm64-v8a. See the script for more details.

Serialization format

Overall, a binary database format which contains deflated JSON or deflated varint-encoded SPIR-V (light compression). The database is a bespoke format with extension ".foz". It is designed to be robust in cases where writes to the database are cut off abrubtly due to external instability issues, which can happen when capturing real applications in a layer which applications might not know about. See fossilize_db.cpp for details on the archive format.

The JSON is a simple format which represents the various Vk*CreateInfo structures. When referring to other VK handle types like pImmutableSamplers in VkDescriptorSetLayout, or VkRenderPass in VkPipeline, a hash is used. 0 represents VK_NULL_HANDLE and anything else represents a key. Small data blobs like specialization constant data are encoded in base64. When recording or replaying, a mapping from and to real Vk object handles must be provided by the application so the key-based indexing scheme can be resolved to real handles.

The varint encoding scheme encodes every 32-bit SPIR-V word by encoding 7 bits at a time starting with the LSBs, the MSB bit in an encoded byte is set if another byte needs to be read (7 bit) for the same SPIR-V word. Each SPIR-V word takes from 1 to 5 bytes with this scheme.

Sample API usage

Recording state

// Note that fossilize.hpp will include Vulkan headers, so make sure you include vulkan.h before
// this one if you care about which Vulkan headers you use.
#include "fossilize.hpp"
#include "fossilize_db.hpp"

void create_state()
{
    auto db = std::unique_ptr<Fossilize::DatabaseInterface>(
            Fossilize::create_database("/tmp/test.foz", Fossilize::DatabaseMode::OverWrite));
    if (!db)
        return;

    Fossilize::StateRecorder recorder;

    // If using a database, you cannot serialize later with recorder.serialize().
    // This is optional.
    // The database method is useful if you intend to replay the archive in fossilize-replay or similar.
    // The recorder interface calls db->prepare(), so it is not necessary to do so here.
    recorder.init_recording_thread(db.get());

    // TODO here: Add way to capture which extensions/physical device features were used to deal with exotic things
    // which require extensions when making repro cases.

    VkDescriptorSetLayoutCreateInfo info = {
        VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO
    };

    // Fill in stuff.
    vkCreateDescriptorSetLayout(..., &layout);

    // Records the descriptor set layout.
    bool success = recorder.record_descriptor_set_layout(layout, info);

    // Do the same for render passes, pipelines, shader modules, samplers (if using immutable samplers) as necessary.

    // If you don't use the database recording thread, you can create a single monolithic JSON,
    // otherwise, just make sure the state recorder is destroyed before the database interface.
    uint8_t *serialized;
    size_t size;
    recorder.serialize(&serialized, &size);
    save_to_disk(serialized, size);
    recorder.free_serialized(serialized);
}

Replaying state

// Note that fossilize.hpp will include Vulkan headers, so make sure you include vulkan.h before
// this one if you care about which Vulkan headers you use.
#include "fossilize.hpp"

struct Device : Fossilize::StateCreatorInterface
{
    // See header for other functions.

    bool enqueue_create_descriptor_set_layout(Hash hash,
                                              const VkDescriptorSetLayoutCreateInfo *create_info,
                                              VkDescriptorSetLayout *layout) override
    {
        // Can queue this up for threaded creation (useful for pipelines).
        // create_info persists as long as Fossilize::Replayer exists.
        VkDescriptorSetLayout set_layout = populate_internal_hash_map(hash, create_info);

        // Let the replayer know how to fill in VkDescriptorSetLayout in upcoming pipeline creation calls.
        // Can use dummy values here if we don't care about using the create_info structs verbatim.
        *layout = set_layout;
        return true;
    }

    void notify_replayed_resources_for_type() override
    {
        // If using multi-threaded creation, join all queued tasks here.
    }

    void sync_threads() override
    {
        // If using multi-threaded creation, join all queued tasks here.
    }

    void sync_threads_modules() override
    {
        // If using multi-threaded creation, join all queued tasks here if we have pending VkShaderModule creations.
    }
};

void replay_state(Device &device)
{
    Fossilize::Replayer replayer;
    bool success = replayer.parse(device, nullptr, serialized_state, serialized_state_size);
    // Now internal hashmaps are warmed up, and all pipelines have been created.

    // It is possible to keep parsing state blobs.
    // This is useful if the state blobs come from Fossilize stream archives.
}

Vulkan layer capture

Fossilize can also capture Vulkan application through the layer mechanism. The layer name is VK_LAYER_fossilize.

To build, enable FOSSILIZE_VULKAN_LAYER CMake option. This is enabled by default. The layer and JSON is placed in layer/ in the build folder.

Linux/Windows

By default the layer will serialize to fossilize.$hash.$index.foz in the working directory on vkDestroyDevice. However, due to the nature of some drivers, there might be crashes in-between. For this, there are two other modes.

export FOSSILIZE=1

Fossilize in an implicit layer with an enable_environment mechanism. Set this environment variable to automatically load the Fossilize layer.

export FOSSILIZE_DUMP_SIGSEGV=1

On Linux and Android, a SIGSEGV handler is registered on instance creation, and the offending pipeline is serialized to disk in the segfault handler. This is very sketchy for general use since it's not guaranteed to work and it overrides any application handlers, but it should work well if drivers are crashing on pipeline creation. On Windows, the global SEH handler is overridden instead.

If an access violation is triggered, the serialization thread is flushed. A message box will appear on Windows, notifying user about this, and immediately terminates the process after.

export FOSSILIZE_DUMP_SYNC=1

Similar to use case for FOSSILIZE_DUMP_SIGSEGV=1, but used when SIGSEGV dumping does not work correctly, e.g. when application relies on using these signal handlers internally. In this mode, all recording is done fully synchronized before calling into drivers, which is robust, but likely very slow.

export FOSSILIZE_DUMP_PATH=/my/custom/path

Custom file path for capturing state. The actual path which is written to disk will be $FOSSILIZE_DUMP_PATH.$hash.$index.foz. This is to allow multiple processes and applications to dump concurrently.

Android

By default the layer will serialize to /sdcard/fossilize.json on vkDestroyDevice. However, this path might not be writeable, so you will probably have to override your path to something like /sdcard/Android/data/<package.name>/capture.json. Make sure your app has external write permissions if using the default path.

Due to the nature of some drivers, there might be crashes in-between. For this, there are two other modes. Options can be set through setprop.

Setprop options

  • setprop debug.fossilize.dump_path /custom/path
  • setprop debug.fossilize.dump_sigsegv 1

To force layer to be enabled outside application: setprop debug.vulkan.layers "VK_LAYER_fossilize". The layer .so needs to be part of the APK for the loader to find the layer.

Use adb logcat -s Fossilize to isolate log messages coming from Fossilize. You should see something like:

04-18 21:49:41.692 17444 17461 I Fossilize: Overriding serialization path: "/sdcard/fossilize.json".
04-18 21:49:43.741 17444 17461 I Fossilize: Serialized to "/sdcard/fossilize.json".

if capturing is working correctly.

CLI

The CLI currently has 3 tools available. These are found in cli/ after build.

fossilize-replay

This tool is for taking a capture, and replaying it on any device. Currently, all basic PhysicalDeviceFeatures (not PhysicalDeviceFeatures2 stuff) and extensions will be enabled to make sure a capture will validate properly. robustBufferAccess however is set to whatever the database has used.

This tool serves as the main "repro" tool as well as a pipeline driver cache warming tool. After you have a capture, you should ideally be able to repro crashes using this tool. To make replay faster, use --graphics-pipeline-range [start-index] [end-index] and --compute-pipeline-range [start-index] [end-index] to isolate which pipelines are actually compiled.

fossilize-merge-db

This tool merges and appends multiple databases into one database.

fossilize-convert-db

This tool can convert the binary Fossilize database to a human readable representation and back to a Fossilize database. This can be used to inspect individual database entries by hand.

fossilize-disasm

NOTE: This tool hasn't been updated since the change to the new database format. It might not work as intended at the moment.

This tool can disassemble any pipeline into something human readable. Three modes are provided:

  • ASM (using SPIRV-Tools)
  • Vulkan GLSL (using SPIRV-Cross)
  • AMD ISA (using VK_AMD_shader_info if available)

TODO is disassembling more of the other state for quick introspection. Currently only SPIR-V disassembly is provided.

fossilize-opt

NOTE: This tool hasn't been updated since the change to the new database format. It might not work as intended at the moment.

Runs spirv-opt over all shader modules in the capture and serializes out an optimized version. Useful to sanity check that an optimized capture can compile on your driver.

Android

Running the CLI apps on Android is also supported. Push the binaries generated to /data/local/tmp, chmod +x them if needed, and use the binaries like regular Linux.

Submit shader failure repro cases

TBD

External modules

fossilize's People

Contributors

1ace avatar aeikum avatar charlie-ht avatar cmarcelo avatar danginsburg avatar ducksoft avatar gfxstrand avatar hakzsam avatar hanskristian-work avatar ibriano avatar ishitatsuyuki avatar joshua-ashton avatar jpark37 avatar kakra avatar mikes-lunarg avatar olvaffe avatar pendingchaos avatar plagman avatar themaister avatar ttimo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fossilize's Issues

Fossilize influenced by I/O load on unrelated drives

Your system information

  • Steam client version (build number or date): latest (Jan 16 2022)
  • Distribution (e.g. Ubuntu): Gentoo
  • Opted into Steam client beta?: [Yes/No] No
  • Have you checked for system updates?: [Yes/No] Yes

Hardware:
3900x
64GB RAM
Rest described below.

When using the following setup with an I/O load fossilize will go down from maxing my processor to using only one core at 50% to having no CPU usage at all.

Setup:
BTRFS RAID0 (2x512GB /)
BTRFS RAID0 (2x10TB /mnt/RAID)
BTRFS Single drive (1x3TB /mnt/RAID/3TB)
Have steam install and download games in /home/user

How to replicate:
Start processing vulkan shaders;
Start transferring files from /mnt/RAID/3TB to /mnt/RAID (this shouldn't cause any problems as the I/O is not on the main drive).

Fossilize now vanishes from system and stops working until the transfer is completed, cancelled or paused.

Reason for bug:

The I/O is not on the main drive that steam is installed on, so it shouldn't affect fossilize. On my 3900x the load average is 3. Plenty of CPU for fossilize to run.

Pausing the transfer results in the CPU suddenly hitting 100% with fossilize using all cores after a second or two.

.xsessions-errors full of warnings

I have almost 400k lines of warnings (and occasional errors) in my current .xsession-errors file that look like this:

Fossilize WARN: Referenced Pipeline layout 363b15eea90822d5, but it does not exist.
This can be expected when replaying an archive from Steam.
If replaying just the application cache, make sure to replay together with the common cache, as application cache can depend on common cache.
Fossilize WARN: Referenced Pipeline layout 5824ee3337152992, but it does not exist.
This can be expected when replaying an archive from Steam.
If replaying just the application cache, make sure to replay together with the common cache, as application cache can depend on common cache.
Fossilize ERROR: Failed to parse pNext chain for sType: 1000320002
Fossilize WARN: Referenced Pipeline layout c34da37358ab927f, but it does not exist.
This can be expected when replaying an archive from Steam.
If replaying just the application cache, make sure to replay together with the common cache, as application cache can depend on common cache.
Fossilize WARN: Referenced Pipeline layout ff633201f6340b62, but it does not exist.
This can be expected when replaying an archive from Steam.
If replaying just the application cache, make sure to replay together with the common cache, as application cache can depend on common cache.
Fossilize WARN: Referenced Pipeline layout ab7c115aa56e8b27, but it does not exist.
This can be expected when replaying an archive from Steam.
If replaying just the application cache, make sure to replay together with the common cache, as application cache can depend on common cache.

Steam System Information: (too long to post here, sorry)
https://privatebin.at/?d00890c32a0829c6#9U9NG2GvESFUWuMza3Q3UPZTABCVm64zj5BRKvjqe5iX

fossilize-replay uses up too much memory (Bioshock Infinite)

[  230.058391] Out of memory: Killed process 2954 (fossilize_repla) total-vm:2958052kB, anon-rss:2297484kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:5272kB oom_score_adj:0

Attempting to replay the steam_pipeline_cache.foz from Bioshock Infinite (8870) distributed by Steam (Proton 7.0-4; AMD VEGA10, also Vangogh) results in excessive memory usage by fossilize-replay. The memory usage seems to scale with the number of threads. For reasons I do not know, Steam on my desktop requests 7 threads but the rest of the threads get killed off shortly after starting and does not trigger an OOM. On the Deck, however, the resulting memory usage causes an OOM condition, which takes down most of the userspace and causes Steam to restart.

Here is the foz db for ease of reproducing: http://www.fastquake.com/files/tmp/steam_pipeline_cache.bioshockinfinite.vega10.proton7-0-4.foz

fossilize ERROR: Detected sliced file. "Dropping entries from here." for ubuntu

Your system information

  • System information from steam (Steam -> Help -> System Information) in a gist:
System Information

* Computer Information:
    Manufacturer:  Unknown
    Model:  Unknown
    Form Factor: Laptop
    No Touch Input Detected

Processor Information:
    CPU Vendor:  GenuineIntel
    CPU Brand:  11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz
    CPU Family:  0x6
    CPU Model:  0x8c
    CPU Stepping:  0x1
    CPU Type:  0x0
    Speed:  4100 Mhz
    4 logical processors
    2 physical processors
    HyperThreading:  Supported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Supported
    SSE4a:  Unsupported
    SSE41:  Supported
    SSE42:  Supported
    AES:  Supported
    AVX:  Supported
    AVX2:  Unsupported
    AVX512F:  Unsupported
    AVX512PF:  Unsupported
    AVX512ER:  Unsupported
    AVX512CD:  Unsupported
    AVX512VNNI:  Supported
    SHA:  Unsupported
    CMPXCHG16B:  Supported
    LAHF/SAHF:  Supported
    PrefetchW:  Unsupported

Operating System Version:
    Ubuntu 20.04.2 LTS (64 bit)
    Kernel Name:  Linux
    Kernel Version:  5.8.0-50-generic
    X Server Vendor:  The X.Org Foundation
    X Server Release:  12009000
    X Window Manager:  GNOME Shell
    Steam Runtime Version:  steam-runtime_0.20210317.0

Video Card:
    Driver:  Intel Mesa Intel(R) UHD Graphics (TGL GT2)
    Driver Version:  4.6 (Compatibility Profile) Mesa 20.2.6
    OpenGL Version: 4.6
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 60 Hz
    VendorID:  0x8086
    DeviceID:  0x9a78
    Revision Not Detected
    Number of Monitors:  2
    Number of Logical Video Cards:  1
    Primary Display Resolution:  1920 x 1080
    Desktop Resolution: 3840 x 1080
    Primary Display Size: 18.78" x 10.55" (21.54" diag)
                                            47.7cm x 26.8cm (54.7cm diag)
    Primary VRAM Not Detected

Sound card:
    Audio device: Realtek ALC236

Memory:
    RAM:  11626 Mb

VR Hardware:
    VR Headset: None detected

Miscellaneous:
    UI Language:  English
    LANG:  en_US.UTF-8
    Total Hard Disk Space Available:  151867 Mb
    Largest Free Hard Disk Block:  2481 Mb

Storage:
    Number of SSDs: 0
    SSD sizes: %s1
    Number of HDDs: 0
    HDD sizes: %s1

"LD_* scout runtime" information:
{
  "can-write-uinput" : true,
  "steam-installation" : {
    "path" : "/home/canerveg/.steam/debian-installation",
    "data_path" : "/home/canerveg/.steam/debian-installation",
    "bin32_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_32",
    "steamscript_path" : null,
    "steamscript_version" : null,
    "issues" : [
      "steamscript-not-in-environment"
    ]
  },
  "runtime" : {
    "path" : "/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime",
    "version" : "0.20210317.0",
    "issues" : [
    ],
    "pinned_libs_32" : {
      "list" : [
        "   136323      4 drwxrwxr-x   2 canerveg canerveg     4096 Nis 16 01:21 pinned_libs_32",
        "   141215      0 -rw-rw-r--   1 canerveg canerveg        0 Nis 16 01:21 pinned_libs_32/has_pins",
        "   141214      4 -rw-rw-r--   1 canerveg canerveg       80 Nis 16 01:21 pinned_libs_32/system_libvulkan.so.1",
        "   141213      4 lrwxrwxrwx   1 canerveg canerveg      111 Nis 16 01:21 pinned_libs_32/libvulkan.so.1 -> /home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libvulkan.so.1.2.170"
      ]
    },
    "pinned_libs_64" : {
      "list" : [
        "   141203      4 drwxrwxr-x   2 canerveg canerveg     4096 Nis 16 01:21 pinned_libs_64",
        "   141204      4 lrwxrwxrwx   1 canerveg canerveg      119 Nis 16 01:21 pinned_libs_64/libdbusmenu-glib.so.4 -> /home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/libdbusmenu-glib.so.4.0.13",
        "   141216      0 lrwxrwxrwx   1 canerveg canerveg       12 Nis 16 01:21 pinned_libs_64/libcurl.so.3 -> libcurl.so.4",
        "   141205      4 -rw-rw-r--   1 canerveg canerveg       97 Nis 16 01:21 pinned_libs_64/system_libdbusmenu-glib.so.4",
        "   141207      4 lrwxrwxrwx   1 canerveg canerveg      112 Nis 16 01:21 pinned_libs_64/libGLU.so.1 -> /home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.08004",
        "   141210      4 -rw-rw-r--   1 canerveg canerveg       78 Nis 16 01:21 pinned_libs_64/system_libcurl.so.4",
        "   141209      4 lrwxrwxrwx   1 canerveg canerveg      109 Nis 16 01:21 pinned_libs_64/libcurl.so.4 -> /home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0",
        "   141206      0 -rw-rw-r--   1 canerveg canerveg        0 Nis 16 01:21 pinned_libs_64/has_pins",
        "   141208      4 -rw-rw-r--   1 canerveg canerveg       76 Nis 16 01:21 pinned_libs_64/system_libGLU.so.1",
        "   141212      4 -rw-rw-r--   1 canerveg canerveg       84 Nis 16 01:21 pinned_libs_64/system_libvulkan.so.1",
        "   141211      4 lrwxrwxrwx   1 canerveg canerveg      113 Nis 16 01:21 pinned_libs_64/libvulkan.so.1 -> /home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/libvulkan.so.1.2.170"
      ]
    }
  },
  "os-release" : {
    "id" : "ubuntu",
    "id_like" : [
      "debian"
    ],
    "name" : "Ubuntu",
    "pretty_name" : "Ubuntu 20.04.2 LTS",
    "version_id" : "20.04",
    "version_codename" : "focal"
  },
  "container" : {
    "type" : "none"
  },
  "driver_environment" : [
    "DISPLAY=:0",
    "LD_LIBRARY_PATH=/home/canerveg/.steam/debian-installation/ubuntu12_32:/home/canerveg/.steam/debian-installation/ubuntu12_32/panorama:/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/pinned_libs_32:/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/pinned_libs_64:/usr/lib/x86_64-linux-gnu/libfakeroot:/lib/i386-linux-gnu:/usr/local/lib:/lib/x86_64-linux-gnu:/lib:/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/lib/i386-linux-gnu:/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu:/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/lib/x86_64-linux-gnu:/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu:/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/lib:/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib",
    "SDL_GAMECONTROLLERCONFIG=03000000de280000ff11000001000000,Steam Virtual Gamepad,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,\n03000000de280000fc11000001000000,Steam Controller,a:b0,b:b1,back:b6,dpdown:b14,dpleft:b15,dpright:b13,dpup:b12,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,",
    "XDG_RUNTIME_DIR=/run/user/1000"
  ],
  "architectures" : {
    "i386-linux-gnu" : {
      "can-run" : true,
      "runtime-linker" : {
        "path" : "/lib/ld-linux.so.2",
        "resolved" : "/usr/lib/i386-linux-gnu/ld-2.31.so"
      },
      "library-issues-summary" : [
      ],
      "graphics-details" : {
        "x11/vulkan" : {
          "messages" : [
            "INTEL-MESA: warning: Vulkan is not yet fully supported on gen12",
            "INTEL-MESA: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0"
          ],
          "renderer" : "Intel(R) UHD Graphics (TGL GT2)",
          "version" : "1.2.145 (device 0x8086:0x9a78) (driver 20.2.6)",
          "devices" : [
            {
              "name" : "Intel(R) UHD Graphics (TGL GT2)",
              "api-version" : "1.2.145",
              "driver-version" : "20.2.6",
              "vendor-id" : "0x8086",
              "device-id" : "0x9a78",
              "type" : "integrated-gpu"
            }
          ]
        },
        "x11/vdpau" : {
          "messages" : [
            "Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory",
            "vdp_device_create_x11 (display, screen, &device, &vdp_get_proc_address) failed: 1"
          ],
          "renderer" : null,
          "version" : null,
          "issues" : [
            "cannot-draw"
          ],
          "exit-status" : 1
        },
        "x11/vaapi" : {
          "messages" : [
            "libva info: VA-API version 1.1.0",
            "libva info: va_getDriverName() returns 0",
            "libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iris_drv_video.so",
            "libva info: Trying to open /usr/lib/i386-linux-gnu/dri/intel-vaapi-driver/iris_drv_video.so",
            "libva info: Trying to open /usr/lib/i386-linux-gnu/GL/lib/dri/iris_drv_video.so",
            "libva info: Trying to open /usr/lib32/dri/iris_drv_video.so",
            "libva info: Trying to open /usr/lib/dri/iris_drv_video.so",
            "libva info: va_openDriver() returns -1",
            "vaInitialize (va_display, &major_version, &minor_version) failed: unknown libva error (-1)"
          ],
          "renderer" : null,
          "version" : null,
          "issues" : [
            "cannot-draw"
          ],
          "exit-status" : 1
        },
        "glx/gl" : {
          "renderer" : "Mesa Intel(R) UHD Graphics (TGL GT2)",
          "version" : "4.6 (Compatibility Profile) Mesa 20.2.6",
          "library-vendor" : "glvnd"
        },
        "egl_x11/gl" : {
          "messages" : [
            "Waffle error: 0x1 WAFFLE_ERROR_FATAL: dlopen(\"libEGL.so.1\") failed: libEGL.so.1: wrong ELF class: ELFCLASS64"
          ],
          "renderer" : null,
          "version" : null,
          "library-vendor" : "unknown",
          "issues" : [
            "cannot-load"
          ],
          "exit-status" : 1
        },
        "egl_x11/glesv2" : {
          "messages" : [
            "Waffle error: 0x1 WAFFLE_ERROR_FATAL: dlopen(\"libEGL.so.1\") failed: libEGL.so.1: wrong ELF class: ELFCLASS64"
          ],
          "renderer" : null,
          "version" : null,
          "library-vendor" : "unknown",
          "issues" : [
            "cannot-load"
          ],
          "exit-status" : 1
        }
      },
      "dri_drivers" : [
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/i915_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/i965_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/iris_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/kms_swrast_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/nouveau_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/nouveau_vieux_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/r200_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/r300_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/r600_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/radeon_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/radeonsi_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/swrast_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/virtio_gpu_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/vmwgfx_dri.so"
        },
        {
          "library_path" : "/usr/lib/i386-linux-gnu/dri/zink_dri.so"
        }
      ],
      "va-api_drivers" : [
        {
          "library_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/dri/dummy_drv_video.so"
        }
      ],
      "vdpau_drivers" : [
        {
          "library_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/vdpau/libvdpau_trace.so.1",
          "library_link" : "libvdpau_trace.so.1.0.0"
        }
      ],
      "glx_drivers" : [
        {
          "library_soname" : "libGLX_indirect.so.0",
          "library_path" : "/usr/lib/i386-linux-gnu/libGLX_mesa.so.0.0.0"
        },
        {
          "library_soname" : "libGLX_mesa.so.0",
          "library_path" : "/usr/lib/i386-linux-gnu/libGLX_mesa.so.0.0.0"
        }
      ]
    },
    "x86_64-linux-gnu" : {
      "can-run" : true,
      "runtime-linker" : {
        "path" : "/lib64/ld-linux-x86-64.so.2",
        "resolved" : "/usr/lib/x86_64-linux-gnu/ld-2.31.so"
      },
      "library-issues-summary" : [
      ],
      "graphics-details" : {
        "x11/vulkan" : {
          "messages" : [
            "INTEL-MESA: warning: Vulkan is not yet fully supported on gen12",
            "INTEL-MESA: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0"
          ],
          "renderer" : "Intel(R) UHD Graphics (TGL GT2)",
          "version" : "1.2.145 (device 0x8086:0x9a78) (driver 20.2.6)",
          "devices" : [
            {
              "name" : "Intel(R) UHD Graphics (TGL GT2)",
              "api-version" : "1.2.145",
              "driver-version" : "20.2.6",
              "vendor-id" : "0x8086",
              "device-id" : "0x9a78",
              "type" : "integrated-gpu"
            }
          ]
        },
        "x11/vdpau" : {
          "messages" : [
            "Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory",
            "vdp_device_create_x11 (display, screen, &device, &vdp_get_proc_address) failed: 1"
          ],
          "renderer" : null,
          "version" : null,
          "issues" : [
            "cannot-draw"
          ],
          "exit-status" : 1
        },
        "x11/vaapi" : {
          "messages" : [
            "libva info: VA-API version 1.1.0",
            "libva info: va_getDriverName() returns 0",
            "libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iris_drv_video.so",
            "libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iris_drv_video.so",
            "libva info: Trying to open /usr/lib/x86_64-linux-gnu/GL/lib/dri/iris_drv_video.so",
            "libva info: Trying to open /usr/lib64/dri/iris_drv_video.so",
            "libva info: Trying to open /usr/lib/dri/iris_drv_video.so",
            "libva info: va_openDriver() returns -1",
            "vaInitialize (va_display, &major_version, &minor_version) failed: unknown libva error (-1)"
          ],
          "renderer" : null,
          "version" : null,
          "issues" : [
            "cannot-draw"
          ],
          "exit-status" : 1
        },
        "glx/gl" : {
          "renderer" : "Mesa Intel(R) UHD Graphics (TGL GT2)",
          "version" : "4.6 (Compatibility Profile) Mesa 20.2.6",
          "library-vendor" : "glvnd"
        },
        "egl_x11/gl" : {
          "renderer" : "Mesa Intel(R) UHD Graphics (TGL GT2)",
          "version" : "4.6 (Compatibility Profile) Mesa 20.2.6",
          "library-vendor" : "glvnd"
        },
        "egl_x11/glesv2" : {
          "renderer" : "Mesa Intel(R) UHD Graphics (TGL GT2)",
          "version" : "OpenGL ES 3.2 Mesa 20.2.6",
          "library-vendor" : "glvnd"
        }
      },
      "dri_drivers" : [
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/i915_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/iris_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/kms_swrast_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/nouveau_vieux_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/r200_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/r300_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/r600_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/radeon_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/virtio_gpu_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so"
        },
        {
          "library_path" : "/usr/lib/x86_64-linux-gnu/dri/zink_dri.so"
        }
      ],
      "va-api_drivers" : [
        {
          "library_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/dri/dummy_drv_video.so"
        }
      ],
      "vdpau_drivers" : [
        {
          "library_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1",
          "library_link" : "libvdpau_trace.so.1.0.0"
        }
      ],
      "glx_drivers" : [
        {
          "library_soname" : "libGLX_indirect.so.0",
          "library_path" : "/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0"
        },
        {
          "library_soname" : "libGLX_mesa.so.0",
          "library_path" : "/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0"
        }
      ]
    }
  },
  "locale-issues" : [
  ],
  "locales" : {
    "<default>" : {
      "resulting-name" : "LC_CTYPE=en_US.UTF-8;LC_NUMERIC=tr_TR.UTF-8;LC_TIME=tr_TR.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=tr_TR.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=tr_TR.UTF-8;LC_NAME=tr_TR.UTF-8;LC_ADDRESS=tr_TR.UTF-8;LC_TELEPHONE=tr_TR.UTF-8;LC_MEASUREMENT=tr_TR.UTF-8;LC_IDENTIFICATION=tr_TR.UTF-8",
      "charset" : "UTF-8",
      "is_utf8" : true
    },
    "C" : {
      "resulting-name" : "C",
      "charset" : "ANSI_X3.4-1968",
      "is_utf8" : false
    },
    "C.UTF-8" : {
      "resulting-name" : "C.UTF-8",
      "charset" : "UTF-8",
      "is_utf8" : true
    },
    "en_US.UTF-8" : {
      "resulting-name" : "en_US.UTF-8",
      "charset" : "UTF-8",
      "is_utf8" : true
    }
  },
  "egl" : {
    "icds" : [
      {
        "json_path" : "/usr/share/glvnd/egl_vendor.d/50_mesa.json",
        "library_path" : "libEGL_mesa.so.0",
        "issues" : [
        ]
      }
    ]
  },
  "vulkan" : {
    "icds" : [
      {
        "json_path" : "/usr/share/vulkan/icd.d/radeon_icd.i686.json",
        "library_path" : "/usr/lib/i386-linux-gnu/libvulkan_radeon.so",
        "api_version" : "1.2.131",
        "issues" : [
        ]
      },
      {
        "json_path" : "/usr/share/vulkan/icd.d/intel_icd.i686.json",
        "library_path" : "/usr/lib/i386-linux-gnu/libvulkan_intel.so",
        "api_version" : "1.2.145",
        "issues" : [
        ]
      },
      {
        "json_path" : "/usr/share/vulkan/icd.d/radeon_icd.x86_64.json",
        "library_path" : "/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so",
        "api_version" : "1.2.131",
        "issues" : [
        ]
      },
      {
        "json_path" : "/usr/share/vulkan/icd.d/intel_icd.x86_64.json",
        "library_path" : "/usr/lib/x86_64-linux-gnu/libvulkan_intel.so",
        "api_version" : "1.2.145",
        "issues" : [
        ]
      }
    ],
    "explicit_layers" : [
      {
        "json_path" : "/usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json",
        "name" : "VK_LAYER_MESA_overlay",
        "description" : "Mesa Overlay layer",
        "type" : "GLOBAL",
        "api_version" : "1.1.73",
        "implementation_version" : "1",
        "library_path" : "libVkLayer_MESA_overlay.so",
        "issues" : [
        ]
      }
    ],
    "implicit_layers" : [
      {
        "json_path" : "/usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json",
        "name" : "VK_LAYER_MESA_device_select",
        "description" : "Linux device selection layer",
        "type" : "GLOBAL",
        "api_version" : "1.1.73",
        "implementation_version" : "1",
        "library_path" : "libVkLayer_MESA_device_select.so",
        "issues" : [
        ]
      },
      {
        "json_path" : "/home/canerveg/.local/share/vulkan/implicit_layer.d/steamfossilize_i386.json",
        "name" : "VK_LAYER_VALVE_steam_fossilize_32",
        "description" : "Steam Pipeline Caching Layer",
        "type" : "GLOBAL",
        "api_version" : "1.2.136",
        "implementation_version" : "1",
        "library_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_32/libVkLayer_steam_fossilize.so",
        "issues" : [
        ]
      },
      {
        "json_path" : "/home/canerveg/.local/share/vulkan/implicit_layer.d/steamfossilize_x86_64.json",
        "name" : "VK_LAYER_VALVE_steam_fossilize_64",
        "description" : "Steam Pipeline Caching Layer",
        "type" : "GLOBAL",
        "api_version" : "1.2.136",
        "implementation_version" : "1",
        "library_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_64/libVkLayer_steam_fossilize.so",
        "issues" : [
        ]
      },
      {
        "json_path" : "/home/canerveg/.local/share/vulkan/implicit_layer.d/steamoverlay_i386.json",
        "name" : "VK_LAYER_VALVE_steam_overlay_32",
        "description" : "Steam Overlay Layer",
        "type" : "GLOBAL",
        "api_version" : "1.2.136",
        "implementation_version" : "1",
        "library_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_32/steamoverlayvulkanlayer.so",
        "issues" : [
        ]
      },
      {
        "json_path" : "/home/canerveg/.local/share/vulkan/implicit_layer.d/steamoverlay_x86_64.json",
        "name" : "VK_LAYER_VALVE_steam_overlay_64",
        "description" : "Steam Overlay Layer",
        "type" : "GLOBAL",
        "api_version" : "1.2.136",
        "implementation_version" : "1",
        "library_path" : "/home/canerveg/.steam/debian-installation/ubuntu12_64/steamoverlayvulkanlayer.so",
        "issues" : [
        ]
      }
    ]
  },
  "desktop-entries" : [
    {
      "id" : "steam.desktop",
      "commandline" : "/usr/games/steam %U",
      "filename" : "/usr/share/applications/steam.desktop",
      "default_steam_uri_handler" : true,
      "steam_uri_handler" : true
    }
  ],
  "xdg-portals" : {
    "details" : {
      "interfaces" : {
        "org.freedesktop.portal.OpenURI" : {
          "available" : true,
          "version" : 3
        },
        "org.freedesktop.portal.Email" : {
          "available" : true,
          "version" : 3
        }
      },
      "backends" : {
        "org.freedesktop.impl.portal.desktop.gtk" : {
          "available" : true
        },
        "org.freedesktop.impl.portal.desktop.kde" : {
          "available" : false
        }
      }
    },
    "issues" : [
    ]
  },
  "cpu-features" : {
    "x86-64" : true,
    "sse3" : true,
    "cmpxchg16b" : true
  }
}

"scout runtime container" is not installed.

"soldier runtime container" is not installed.

  • Have you checked for system updates?: yes. latest
  • Are you using the latest stable video driver available for your system? yes
  • Have you verified the game files?: yes. twice.

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Today it started. I could play until today without any errors. I restarted also. I got this error when i start:
fossilize ERROR: Detected sliced file. "Dropping entries from here."

Steps for reproducing this issue:

  1. Open steam
  2. Open dota 2
  3. It gives error

image

I never used compatibiltiy tool . But after this error, i chose 6.3.3 proton. it downloaded. it tried to open dota but maybebecause i dobnt have gpu, it immediately closed.

I can also play cs go still without any errors.

I dont have any launch options. I just start from icon always.

Dota 2 Vulkan shader cache duration?

Shaders seem to be recompiled almost every time I launch the game. It used to be once per update more or less but now if the game is closed for more than an hour or so I have to wait for "Processing Vulkan Shaders"

I had temporarily set the launch flag to not cache while debugging another issue (turned out to be an issue with gamemoderun) but have since removed it. Caching has not worked since.

Feature Request: Save processed shaders to disk, prevent re-processing on each run

Please let me know if this is not the correct repo - I had no idea where to make a note of this.

It takes about 10-20 minutes for fossilize to process GTA V shaders on my machine, and this happens each time I start the game. It seems redundant to do this process more than once, and it seems to me that naively, a user option could be added to save the processed shaders on-disk so that you are not running the same computations each time a game is started.

image

This is a fantastic piece of technology however, and thank you to everyone at Valve for maintaining it.

fossilize_replay uses only single thread

Actual behavior: Starting Warframe under Linux takes over 20 minutes as fossilize_replay uses single thread only.

Expected: All CPU threads are utilized

command being run by steam:

~/.steam/debian-installation/ubuntu12_32/../ubuntu12_64/fossilize_replay ~/.steam/debian-installation/steamapps/shadercache/230410/fozpipelinesv4/steamapp_pipeline_cache.foz ~/.steam/debian-installation/steamapps/shadercache/230410/fozpipelinesv4/steam_pipeline_cache.foz --master-process --quiet-slave --shmem-fd 96 --spirv-val --on-disk-validation-whitelist ~/.steam/debian-installation/steamapps/shadercache/230410/fozpipelinesv4/steam_pipeline_cache_whitelist --device-index 0 --timeout-seconds 10 --implicit-whitelist 0

Package: steam:i386 Version: 1.0.0.64-1 Priority: optional Section: non-free/games Maintainer: Debian Games Team <[email protected]> Installed-Size: 4,807 kB Pre-Depends: debconf Depends: curl, file, libgcc-s1 | libgcc1, libgl1-mesa-dri (>= 17.3), libgl1, libgpg-error0 (>= 1.10), libstdc++6 (>= 4.8), libudev1, libxcb-dri3-0 (>= 1.11.1), libxcb1, libxinerama1 (>= 2:1.1.1), xz-utils, debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.15), libx11-6 Recommends: ca-certificates, fontconfig, fonts-liberation, libxss1, mesa-vulkan-drivers, steam-devices, xdg-utils, xterm | x-terminal-emulator, zenity Suggests: nvidia-driver-libs-i386, nvidia-vulkan-icd Conflicts: steam-launcher Replaces: steam-launcher Homepage: https://steamcommunity.com/linux Download-Size: 1,548 kB APT-Manual-Installed: yes APT-Sources: https://deb.debian.org/debian testing/non-free i386 Packages Description: Valve's Steam digital software delivery system Steam (https://www.steampowered.com) is a software content delivery system developed by Valve software (https://www.valvesoftware.com). There is some free software available, but for the most part the content delivered is non-free. . This package comes with a fairly substantial non-free license agreement that must be accepted before installing the software. If you have any opposition to non-free work, please select "I DECLINE" during the package installation dialogs. There are also additional agreements in various parts of the application that differ from the original agreement. In other words, pay attention and read carefully if you're worried about your rights.

Linux <hostname> 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64 GNU/Linux

fossilize_replay should use batch scheduling if possible and share resources better

When using schedutil -B $(pgrep fossilize) to put the replayer into batch scheduling mode, it utilizes my CPU better (99.9 to 100% per core instead of 91-98%), and it results in better IO rates writing the data back. This is probably because batch scheduling gives processes bigger time slices at the cost of latency but with better CPU cache hit rate in turn. This also results in better IO coalescing. Additionally, batch jobs should have a slight scheduling penalty over interactive processes, resulting in better system responsiveness while those are running.

But my biggest concern is with it's CPU weight and memory usage: Because those jobs use every core in my system, their CPU share is quite high above other processes. This even continues to work with a high CPU share while in games, and it seems to draw a lot of processing power from CPU and GPU even tho the processes run with nice=19.

So let's inspect this a little further: Modern distro kernels usually use auto-group CPU scheduling, especially when tailored for desktops. This makes sense, as CPU shares are distributed evenly among groups of processes instead of single processes: This essentially makes the scheduler see a complete application packages with all its sub-processes as a single process when it comes to distributing CPU shares. But this also means that nice=19 has absolutely no value because it is considered only among its own group of processes, the group itself will still receive its fair share - so a game running concurrently with the group of replay processes will only get 50% of the CPU. This has become very apparent to me since KDE switched to using slices and scopes for managing apps started from Plasma: I now see an app.slice which shares its total CPU bandwidth with other slices in the system, resulting in the share left to it evenly distributed between each scope running inside, with Steam and all its sub-processes being one such scope. I think Gnome deployed something similar. Maybe Steam just needs to take care that fossilize_replay doesn't create its own auto-group for the scheduler? I'm not if it does.

Also, when looking at memory accounting, I see the process group accounting for over 21 GB of memory on my system. The processes RSS itself only adds up to maybe roughly 8 GB. This is because memory accounting also accounts the page cache occupied by these processes. Or in other words: The replay jobs thrash the page cache, dominating it above other processes of the system. This slows loading times in games a lot.

A way around this would be to put this background job into its own cgroup, and giving that cgroup a much lower CPU share than default. Also, the cgroup could limit the amount of memory used, tho this has to be selected very very carefully or you negate its effects (as in "priority inversion"). A good compromise would be if you could use systemd API on supported distros to create a slice by a defined name for the fossilize jobs. Then, users could create a systemd slice unit to adjust the settings to their preference, limiting CPU and IO shares that way, maybe limiting its share to the bandwidth of one core (which applies only if other processes actually claim the rest). This will open an opportunity for users to experiment with some settings and see what works best, then maybe share their results here. On non-systemd systems, this could either be a no-op, or you could programmatically create a cgroup. I'd opt-in for the no-op option because most distros switched to systemd anyways. To me, it looks like the group of fossilize_replay processes always get a total of 50% CPU share when running concurrently with a game, and this is probably due to auto-grouping or desktop environments putting each app into a systemd scope.

Another question is: Why doesn't fossilize_replay stop when I start playing a game?

BTW: My system probably doesn't use auto-group scheduling because I'm using the CK patchset. Still, nice=19 doesn't have a very big impact because fossilize_replay still seems to use GPU (according to nvidia-smi), and that doesn't know of niceness. So maybe fossilize_replay should not use GPU at all, or it should stop using GPU as soon as a game is being played?

IOW, nice doesn't do what one would expect on modern kernels. See man 7 sched, section "The autogroup feature". Maybe use the autogroup nice feature described there? However, that may not work when apps are already running within a slice or scope.

dynamic state3 + GPL brokenness

A couple different items:

Zink uses GPL with a fragment output stage that uses the forbidden trio of VK_DYNAMIC_STATE_COLOR_BLEND_ENABLE_EXT,
VK_DYNAMIC_STATE_COLOR_BLEND_EQUATION_EXT, and VK_DYNAMIC_STATE_COLOR_WRITE_MASK_EXT. According to the spec:

pAttachments is a pointer to an array of VkPipelineColorBlendAttachmentState structures defining blend state for each color attachment. It is ignored if the pipeline is created with VK_DYNAMIC_STATE_COLOR_BLEND_ENABLE_EXT, VK_DYNAMIC_STATE_COLOR_BLEND_EQUATION_EXT, and VK_DYNAMIC_STATE_COLOR_WRITE_MASK_EXT dynamic states set.

This is not handled correctly, and fossilize crashes from attempting to access the null pAttachments pointer.

Additionally, VkPipelineRenderingCreateInfo is accessed improperly in non-fragment_output stages for GPL pipelines. According to spec, formats may only be accessed in fragment output stage.

Multiview

When using a VkRenderPassMultiviewCreateInfo object in VkRenderPassCreateInfo::pNext I get the following error:

Fossilize ERROR: Error: pNext in VkRenderPassCreateInfo not supported. (pNext->sType chain: [1000053000])
Fossilize ERROR: Failed to record render pass.

Multiview is core in Vulkan 1.1, with a minimum of six passes supported:

Usage:
https://github.com/SaschaWillems/Vulkan/blob/master/examples/multiview/multiview.cpp

VkRenderPassMultiviewCreateInfo renderPassMultiviewCI = {};
if (layers > 1)
{
	uint32_t viewMask = 0;// 0b00111111;
	uint32_t correlationMask = 0;// 0b00111111;
	for (int n = 0; n < layers; ++n)
	{
		viewMask += pow(2, n);
		correlationMask += pow(2, n);
	}
	if (layers == 6) Assert(viewMask == 0b00111111);
	renderPassMultiviewCI.sType = VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO;
	renderPassMultiviewCI.subpassCount = 1;
	renderPassMultiviewCI.pViewMasks = &viewMask;
	renderPassMultiviewCI.correlationMaskCount = 1;
	renderPassMultiviewCI.pCorrelationMasks = &correlationMask;
	renderPassInfo.pNext = &renderPassMultiviewCI;
}

Shader compilation freezes the system

Your system information

  • Steam client version (build number or date): 1676336721 Feb 14 2023, at 00:47:47
  • Distribution (e.g. Ubuntu): Feodara Silverblue 37
  • Opted into Steam client beta?: No
  • Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

On a laptop if steam is launched with dGPU from gnome application launcher or with switcherooctl shader compilation takes more cpu and ram to compile shaders (This can cause whole system to freeze). If steam is started with DRI_PRIME=1 than shader compilation is almost instant and uses little resources.

Steps for reproducing this issue:

  1. start steam with DRI_PRIME=1
  2. run shader_prune
  3. start the game
  4. start steam with switcherooctl dGPU option (DRI_PRIME=pci-0000_03_00_0 for example)
  5. run shader_prune
  6. start the game

On step 3 shader compilation is quick
On step 6 shader compilation can freeze the system

System info
Processor Information:
      CPU Vendor:  AuthenticAMD
      CPU Brand:  AMD Ryzen 9 5900HX with Radeon Graphics        
      CPU Family:  0x19
      CPU Model:  0x50
      CPU Stepping:  0x0
      CPU Type:  0x0
      Speed:  4888 Mhz
      16 logical processors
      8 physical processors
      HyperThreading:  Supported
      FCMOV:  Supported
      SSE2:  Supported
      SSE3:  Supported
      SSSE3:  Supported
      SSE4a:  Supported
      SSE41:  Supported
      SSE42:  Supported
      AES:  Supported
      AVX:  Supported
      AVX2:  Supported
      AVX512F:  Unsupported
      AVX512PF:  Unsupported
      AVX512ER:  Unsupported
      AVX512CD:  Unsupported
      AVX512VNNI:  Unsupported
      SHA:  Supported
      CMPXCHG16B:  Supported
      LAHF/SAHF:  Supported
      PrefetchW:  Unsupported
  
  Operating System Version:
      Freedesktop.org SDK 22.08 (Flatpak runtime) (64 bit)
      Kernel Name:  Linux
      Kernel Version:  6.1.11-200.fc37.x86_64
      X Server Vendor:  The X.Org Foundation
      X Server Release:  12201008
      X Window Manager:  GNOME Shell
      Steam Runtime Version:  steam-runtime_0.20221019.0
  
  Video Card:
      Driver:  AMD AMD Radeon RX 6800M (navi22, LLVM 15.0.7, DRM 3.49, 6.1.11-200.fc37.x86_64)
      Driver Version:  4.6 (Compatibility Profile) Mesa 22.3.4 (git-a5ffb70f86)
      OpenGL Version: 4.6
      Desktop Color Depth: 24 bits per pixel
      Monitor Refresh Rate: 59 Hz
      VendorID:  0x1002
      DeviceID:  0x1638
      Revision Not Detected
      Number of Monitors:  2
      Number of Logical Video Cards:  1
      Primary Display Resolution:  2560 x 1440
      Desktop Resolution: 4480 x 1440
      Primary Display Size: 13.39" x 7.48" (15.31" diag)
                                              34.0cm x 19.0cm (38.9cm diag)
      Primary VRAM: 12288 MB

wishlist feature: pipeline compile timing output

I want to be able to extract a pipeline that takes a long time to compile from a foz file. Currently I have to do something like

for x in $(fossilize-list --tag 6 file.foz); do fossilize-replay --pipeline-hash $x file.foz ;done

and iterate over all of them with in-driver printfs to check the timing. It would be more convenient if fossilize could provide this sort of timing, or maybe output a list of slowest compiles?

Steam seems to never finish shader pre-compiling in the background for A Hat in Time

Your system information

  • Steam client version (build number or date): Wed, Jun 21 6:18 PM UTC -03:00

  • Distribution (e.g. Ubuntu): Fedora Silverblue 38, running as a Flatpak

  • Opted into Steam client beta?: [Yes/No] Yes

  • Have you checked for system updates?: [Yes/No] Yes

  • Steam Logs: [generate by running this command in a terminal tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs] steam-logs.tar.gz

  • GPU: NVIDIA GeForce GTX 1660 Ti / Intelยฎ UHD Graphics 630

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

I have the option "Allow background processing of Vulkan shaders enabled" and I have several games installed, including A Hat in Time".
There's seems to be no indicator right now on the Steam UI that it's doing shader processing (there was one before the rollout of the new UI, I didn't find it after the redesign), but I can know due to the fan of the laptop speeding up.

The problem seems to be that the A Hat in Time shader compiling never finishes, I know it's stuck in the A Hat In time compiling because by checking htop fossilize_replay is working on the Steam app with the id of 253230 (which is A Hat in Time), also if I manually try to load A Hat in Time, but the compilation at that point also takes a long time, so I given up.
Letting the computer go 3 hours straight doing not more then shader compiling seems to not help, as apaprently it still doesn't do much progress.

Also, it seems sometimes the fossilize_replay can be crash, such as this:

jun 21 22:14:34 centauro kernel: traps: fossilize_repla[17788] general protection fault ip:7fd6aca926a4 sp:7ffd57e75568 error:0 in libc.so.6[7fd6aca28000+180000]
jun 21 22:14:36 centauro systemd-coredump[18576]: [๐Ÿก•] Process 17788 (fossilize_repla) of user 1000 dumped core.
                                                  
                                                  Stack trace of thread 1984:
                                                  #0  0x00007fd6aca926a4 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x926a4)
                                                  ELF object binary architecture: AMD x86-64

Steps for reproducing this issue:

  1. Enable "Allow background processing of Vulkan shaders" feature
  2. Install A Hat In Time
  3. Check if it properly compiles A Hat In Time shaders

fossilize-synth/fossilize-disasm with only vertex or fragment shader?

I'm looking at adding Shader Playground support for ACO, but that website seems to only support one shader stage at a time. fossilize-synth and fossilize-disasm seem to do a lot of what I want already, but supplying just a vertex or fragment shader without the other to fossilize-synth leads to a graphics pipeline not being generated.

I tried making some changes to support creating vertex-only graphics pipelines, which kind of works, but the interpolants get optimized away, which isn't what I want for this use case. It seems like I would need to reflect the vertex shader, and create a dummy fragment shader to ensure the interpolants are used. Likewise for the fragment-only case, I would need to create a dummy vertex shader outputting fragment shader inputs to even have a valid graphics pipeline.

Does this sound accurate? If you want any of these changes (vert-only graphics pipeline, --autovert, --autofrag), I can attempt PRs for them.

Repeated core dumps

# coredumpctl debug 21783
           PID: 21783 (fossilize_repla)
           UID: 500 (kakra)
           GID: 500 (kakra)
        Signal: 11 (SEGV)
     Timestamp: Thu 2023-01-12 18:08:39 CET (18h ago)
  Command Line: /home/kakra/.local/share/Steam/ubuntu12_32/../ubuntu12_64/fossilize_replay /mnt/xfs-storage/kakra/shadercache/8870/fozpipelinesv6/steamapprun_pipeline_cache.904f69d2b1b44b65/steamapp_pipeline_cache.foz /mnt/xfs-storage/kakra/shadercache/8870/fozpipelinesv6/steamapprun_pipeline_cache.904f69d2b1b44b65/steam_pipeline_cache.foz --master-process --quiet-slave --shmem-fd 141 --control-fd 160 --spirv-val --num-threads 5 --on-disk-validation-whitelist /mnt/xfs-storage/kakra/shadercache/8870/fozpipelinesv6/steamapprun_pipeline_cache.904f69d2b1b44b65/steam_pipeline_cache_whitelist --replayer-cache /mnt/xfs-storage/kakra/shadercache/8870/fozpipelinesv6/steamapprun_pipeline_cache.904f69d2b1b44b65/replay_cache --device-index 0 --timeout-seconds 10 --implicit-whitelist 0
    Executable: /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay
 Control Group: /user.slice/user-500.slice/[email protected]/app.slice/app-steam-dc690f3983d14de3ae92987b8033b778.scope
          Unit: [email protected]
     User Unit: app-steam-dc690f3983d14de3ae92987b8033b778.scope
         Slice: user-500.slice
     Owner UID: 500 (kakra)
       Boot ID: 99d3c1cb2f59441bb087e7dae3738fb6
    Machine ID: 121b87ca633e8ac0016656680000001b
      Hostname: jupiter
       Storage: /var/lib/systemd/coredump/core.fossilize_repla.500.99d3c1cb2f59441bb087e7dae3738fb6.21783.1673543319000000.zst (present)
  Size on Disk: 74.3M
       Message: Process 21783 (fossilize_repla) of user 500 dumped core.

                Module libVkLayer_MESA_device_select.so without build-id.
                Module libxcb-glx.so.0 without build-id.
                Module libXext.so.6 without build-id.
                Module libX11.so.6 without build-id.
                Module libmd.so.0 without build-id.
                Module libbsd.so.0 without build-id.
                Module libXdmcp.so.6 without build-id.
                Module libXau.so.6 without build-id.
                Module libgcc_s.so.1 without build-id.
                Module libffi.so.8 without build-id.
                Module libstdc++.so.6 without build-id.
                Module libxshmfence.so.1 without build-id.
                Module libxcb-shm.so.0 without build-id.
                Module libxcb-randr.so.0 without build-id.
                Module libxcb-sync.so.1 without build-id.
                Module libxcb-xfixes.so.0 without build-id.
                Module libxcb-present.so.0 without build-id.
                Module libX11-xcb.so.1 without build-id.
                Module libxcb.so.1 without build-id.
                Module libunwind.so.8 without build-id.
                Module libzstd.so.1 without build-id.
                Module libexpat.so.1 without build-id.
                Module libudev.so.1 without build-id.
                Module libz.so.1 without build-id.
                Module libwayland-client.so.0 without build-id.
                Module libxcb-dri3.so.0 without build-id.
                Module libdrm.so.2 without build-id.
                Module libm.so.6 without build-id.
                Module libvulkan.so.1 without build-id.
                Module ld-linux-x86-64.so.2 without build-id.
                Module libc.so.6 without build-id.
                Module libpthread.so.0 without build-id.
                Module librt.so.1 without build-id.
                Module libdl.so.2 without build-id.
                Stack trace of thread 21783:
                #0  0x0000560393a1f14e n/a (/home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay + 0x6814e)
                ELF object binary architecture: AMD x86-64

GNU gdb (Gentoo 12.1 vanilla) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay...
(No debugging symbols found in /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay)

warning: Can't open file /dev/shm/fossilize-replayer-21615-0 (deleted) during file-backed mapping note processing

warning: Can't open file /dev/shm/fossilize-external-3909967-8 (deleted) during file-backed mapping note processing

warning: core file may not match specified executable file.
[New LWP 21783]
[New LWP 21799]
[New LWP 21792]
[New LWP 21790]
[New LWP 21794]
[New LWP 21793]
[New LWP 21797]
[New LWP 21795]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Core was generated by `/home/kakra/.local/share/Steam/ubuntu12_32/../ubuntu12_64/fossilize_replay /mnt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000560393a1f14e in _start ()
[Current thread is 1 (Thread 0x7f0c27efb780 (LWP 21783))]
(gdb) thread apply all bt full

Thread 8 (Thread 0x7f0c153f46c0 (LWP 21795)):
#0  0x00007f0c27ff0bcf in __GI___poll (fds=0x56039a1dfb90, nfds=3, timeout=100) at ../sysdeps/unix/sysv/linux/poll.c:29
        sc_ret = -516
        sc_cancel_oldtype = 0
        sc_ret = <optimized out>
#1  0x00007f0c1de91f39 in ?? () from /usr/lib64/libcuda.so.1
No symbol table info available.
#2  0x00007f0c1df46014 in ?? () from /usr/lib64/libcuda.so.1
No symbol table info available.
#3  0x00007f0c1de948b8 in ?? () from /usr/lib64/libcuda.so.1
No symbol table info available.
#4  0x00007f0c27f7f802 in start_thread (arg=<optimized out>) at pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        out = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140733106809008, 5509516906133591195, 139689872803520, 2, 139690186896768, 139689864413184, -5589646562614963045, -5589543828881795941}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#5  0x00007f0c27ffe3ec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.

Thread 7 (Thread 0x7f0c127926c0 (LWP 21797)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7f0c12791d30, op=393, expected=0, futex_word=0x7f0bdc000d48) at futex-internal.c:57
        sc_cancel_oldtype = 0
        __arg6 = <optimized out>
        __arg3 = <optimized out>
        _a5 = <optimized out>
        _a2 = <optimized out>
        sc_ret = <optimized out>
        __arg4 = <optimized out>
        __arg1 = <optimized out>
        _a6 = <optimized out>
        _a3 = <optimized out>
        resultvar = <optimized out>
        __arg5 = <optimized out>
        __arg2 = <optimized out>
        _a4 = <optimized out>
        _a1 = <optimized out>
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f0bdc000d48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f0c12791d30, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
        err = <optimized out>
        clockbit = 256
        op = 393
#2  0x00007f0c27f7c4ab in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f0bdc000d48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f0c12791d30, private=pri--Type <RET> for more, q to quit, c to continue without paging--c
vate@entry=0) at futex-internal.c:139
No locals.
#3  0x00007f0c27f7eef4 in __pthread_cond_wait_common (abstime=0x7f0c12791d30, clockid=0, mutex=0x560396c126e0, cond=0x7f0bdc000d20) at pthread_cond_wait.c:503
        spin = 0
        buffer = {__routine = 0x7f0c27f7e960 <__condvar_cleanup_waiting>, __arg = 0x7f0c12791cc0, __canceltype = -1770092744, __prev = 0x0}
        cbuffer = {wseq = 2368, cond = 0x7f0bdc000d20, mutex = 0x560396c126e0, private = 0}
        err = <optimized out>
        g = 0
        flags = <optimized out>
        g1_start = <optimized out>
        maxspin = 0
        signals = <optimized out>
        result = 0
        wseq = 2368
        seq = 1184
        private = 0
        maxspin = <optimized out>
        err = <optimized out>
        result = <optimized out>
        wseq = <optimized out>
        g = <optimized out>
        seq = <optimized out>
        flags = <optimized out>
        private = <optimized out>
        signals = <optimized out>
        done = <optimized out>
        g1_start = <optimized out>
        spin = <optimized out>
        buffer = <optimized out>
        cbuffer = <optimized out>
        s = <optimized out>
#4  ___pthread_cond_timedwait64 (cond=0x7f0bdc000d20, mutex=0x560396c126e0, abstime=0x7f0c12791d30) at pthread_cond_wait.c:643
        flags = <optimized out>
        clockid = 0
#5  0x00007f0c22a6c820 in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#6  0x00007f0c22f441ce in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#7  0x00007f0c22f3cddd in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#8  0x00007f0c22a6f7da in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#9  0x00007f0c27f7f802 in start_thread (arg=<optimized out>) at pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        out = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140733106810576, 5509516906133591195, 139689826264768, 2, 139690186896768, 139689817874432, -5589643761222544229, -5589543828881795941}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#10 0x00007f0c27ffe3ec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.

Thread 6 (Thread 0x7f0c1699c6c0 (LWP 21793)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7f0c1699be00, op=393, expected=0, futex_word=0x7f0bec000d48) at futex-internal.c:57
        sc_cancel_oldtype = 0
        __arg6 = <optimized out>
        __arg3 = <optimized out>
        _a5 = <optimized out>
        _a2 = <optimized out>
        sc_ret = <optimized out>
        __arg4 = <optimized out>
        __arg1 = <optimized out>
        _a6 = <optimized out>
        _a3 = <optimized out>
        resultvar = <optimized out>
        __arg5 = <optimized out>
        __arg2 = <optimized out>
        _a4 = <optimized out>
        _a1 = <optimized out>
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f0bec000d48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f0c1699be00, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
        err = <optimized out>
        clockbit = 256
        op = 393
#2  0x00007f0c27f7c4ab in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f0bec000d48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f0c1699be00, private=private@entry=0) at futex-internal.c:139
No locals.
#3  0x00007f0c27f7eef4 in __pthread_cond_wait_common (abstime=0x7f0c1699be00, clockid=0, mutex=0x560397f9f2c0, cond=0x7f0bec000d20) at pthread_cond_wait.c:503
        spin = 0
        buffer = {__routine = 0x7f0c27f7e960 <__condvar_cleanup_waiting>, __arg = 0x7f0c1699bd90, __canceltype = 370786304, __prev = 0x0}
        cbuffer = {wseq = 240, cond = 0x7f0bec000d20, mutex = 0x560397f9f2c0, private = 0}
        err = <optimized out>
        g = 0
        flags = <optimized out>
        g1_start = <optimized out>
        maxspin = 0
        signals = <optimized out>
        result = 0
        wseq = 240
        seq = 120
        private = 0
        maxspin = <optimized out>
        err = <optimized out>
        result = <optimized out>
        wseq = <optimized out>
        g = <optimized out>
        seq = <optimized out>
        flags = <optimized out>
        private = <optimized out>
        signals = <optimized out>
        done = <optimized out>
        g1_start = <optimized out>
        spin = <optimized out>
        buffer = <optimized out>
        cbuffer = <optimized out>
        s = <optimized out>
#4  ___pthread_cond_timedwait64 (cond=0x7f0bec000d20, mutex=0x560397f9f2c0, abstime=0x7f0c1699be00) at pthread_cond_wait.c:643
        flags = <optimized out>
        clockid = 0
#5  0x00007f0c22a6c820 in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#6  0x00007f0c22eb667d in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#7  0x00007f0c22a6f7da in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#8  0x00007f0c27f7f802 in start_thread (arg=<optimized out>) at pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        out = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140733106811280, 5509516906133591195, 139689895511744, 2, 139690186896768, 139689887121408, -5589651738050554725, -5589543828881795941}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#9  0x00007f0c27ffe3ec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.

Thread 5 (Thread 0x7f0c1619b6c0 (LWP 21794)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7f0be4000d48) at futex-internal.c:57
        sc_cancel_oldtype = 0
        __arg6 = <optimized out>
        __arg3 = <optimized out>
        _a5 = <optimized out>
        _a2 = <optimized out>
        sc_ret = <optimized out>
        __arg4 = <optimized out>
        __arg1 = <optimized out>
        _a6 = <optimized out>
        _a3 = <optimized out>
        resultvar = <optimized out>
        __arg5 = <optimized out>
        __arg2 = <optimized out>
        _a4 = <optimized out>
        _a1 = <optimized out>
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f0be4000d48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
        err = <optimized out>
        clockbit = 256
        op = 393
#2  0x00007f0c27f7c4ab in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f0be4000d48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
No locals.
#3  0x00007f0c27f7ebf0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5603980b6e30, cond=0x7f0be4000d20) at pthread_cond_wait.c:503
        spin = 0
        buffer = {__routine = 0x7f0c27f7e960 <__condvar_cleanup_waiting>, __arg = 0x7f0c1619ad80, __canceltype = -469762000, __prev = 0x0}
        cbuffer = {wseq = 0, cond = 0x7f0be4000d20, mutex = 0x5603980b6e30, private = 0}
        err = <optimized out>
        g = 0
        flags = <optimized out>
        g1_start = <optimized out>
        maxspin = 0
        signals = <optimized out>
        result = 0
        wseq = 0
        seq = 0
        private = 0
        maxspin = <optimized out>
        err = <optimized out>
        result = <optimized out>
        wseq = <optimized out>
        g = <optimized out>
        seq = <optimized out>
        flags = <optimized out>
        private = <optimized out>
        signals = <optimized out>
        done = <optimized out>
        g1_start = <optimized out>
        spin = <optimized out>
        buffer = <optimized out>
        cbuffer = <optimized out>
        s = <optimized out>
#4  ___pthread_cond_wait (cond=0x7f0be4000d20, mutex=0x5603980b6e30) at pthread_cond_wait.c:618
No locals.
#5  0x00007f0c22a6c7bf in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#6  0x00007f0c22eab070 in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#7  0x00007f0c22a6f7da in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#8  0x00007f0c27f7f802 in start_thread (arg=<optimized out>) at pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        out = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140733106811248, 5509516906133591195, 139689887119040, 2, 139690186896768, 139689878728704, -5589652837025311589, -5589543828881795941}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#9  0x00007f0c27ffe3ec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.

Thread 4 (Thread 0x7f0c1799e6c0 (LWP 21790)):
#0  0x00007f0c27ff0bcf in __GI___poll (fds=0x5603980b6e70, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
        sc_ret = -516
        sc_cancel_oldtype = 0
        sc_ret = <optimized out>
#1  0x00007f0c1de91f39 in ?? () from /usr/lib64/libcuda.so.1
No symbol table info available.
#2  0x00007f0c1df46014 in ?? () from /usr/lib64/libcuda.so.1
No symbol table info available.
#3  0x00007f0c1de948b8 in ?? () from /usr/lib64/libcuda.so.1
No symbol table info available.
#4  0x00007f0c27f7f802 in start_thread (arg=<optimized out>) at pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        out = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140733106810992, 5509516906133591195, 139689912297152, 17, 139690186896768, 139689903906816, -5589649535806073701, -5589543828881795941}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#5  0x00007f0c27ffe3ec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.

Thread 3 (Thread 0x7f0c1719d6c0 (LWP 21792)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7f0c1719cdb0, op=393, expected=0, futex_word=0x7f0bfc000d48) at futex-internal.c:57
        sc_cancel_oldtype = 0
        __arg6 = <optimized out>
        __arg3 = <optimized out>
        _a5 = <optimized out>
        _a2 = <optimized out>
        sc_ret = <optimized out>
        __arg4 = <optimized out>
        __arg1 = <optimized out>
        _a6 = <optimized out>
        _a3 = <optimized out>
        resultvar = <optimized out>
        __arg5 = <optimized out>
        __arg2 = <optimized out>
        _a4 = <optimized out>
        _a1 = <optimized out>
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f0bfc000d48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f0c1719cdb0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
        err = <optimized out>
        clockbit = 256
        op = 393
#2  0x00007f0c27f7c4ab in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f0bfc000d48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f0c1719cdb0, private=private@entry=0) at futex-internal.c:139
No locals.
#3  0x00007f0c27f7eef4 in __pthread_cond_wait_common (abstime=0x7f0c1719cdb0, clockid=0, mutex=0x560397fa2d90, cond=0x7f0bfc000d20) at pthread_cond_wait.c:503
        spin = 0
        buffer = {__routine = 0x7f0c27f7e960 <__condvar_cleanup_waiting>, __arg = 0x7f0c1719cd40, __canceltype = 959592758, __prev = 0x0}
        cbuffer = {wseq = 120, cond = 0x7f0bfc000d20, mutex = 0x560397fa2d90, private = 0}
        err = <optimized out>
        g = 0
        flags = <optimized out>
        g1_start = <optimized out>
        maxspin = 0
        signals = <optimized out>
        result = 0
        wseq = 120
        seq = 60
        private = 0
        maxspin = <optimized out>
        err = <optimized out>
        result = <optimized out>
        wseq = <optimized out>
        g = <optimized out>
        seq = <optimized out>
        flags = <optimized out>
        private = <optimized out>
        signals = <optimized out>
        done = <optimized out>
        g1_start = <optimized out>
        spin = <optimized out>
        buffer = <optimized out>
        cbuffer = <optimized out>
        s = <optimized out>
#4  ___pthread_cond_timedwait64 (cond=0x7f0bfc000d20, mutex=0x560397fa2d90, abstime=0x7f0c1719cdb0) at pthread_cond_wait.c:643
        flags = <optimized out>
        clockid = 0
#5  0x00007f0c22a6c820 in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#6  0x00007f0c22e911d2 in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#7  0x00007f0c22a6f7da in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#8  0x00007f0c27f7f802 in start_thread (arg=<optimized out>) at pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        out = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140733106811200, 5509516906133591195, 139689903904448, 2, 139690186896768, 139689895514112, -5589650634780830565, -5589543828881795941}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#9  0x00007f0c27ffe3ec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.

Thread 2 (Thread 0x7f0c11f916c0 (LWP 21799)):
#0  0x00007f0c22dbb29e in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#1  0x00007f0c22e447d7 in ?? () from /usr/lib64/libnvidia-glcore.so.525.78.01
No symbol table info available.
#2  0x00007f0c2418f424 in ?? () from /home/kakra/.local/share/Steam/ubuntu12_64/steamoverlayvulkanlayer.so
No symbol table info available.
#3  0x00007f0c24193ecf in vkDestroyDevice () from /home/kakra/.local/share/Steam/ubuntu12_64/steamoverlayvulkanlayer.so
No symbol table info available.
#4  0x0000560394b51c30 in ?? ()
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 0x7f0c27efb780 (LWP 21783)):
#0  0x0000560393a1f14e in _start ()
No symbol table info available.
(gdb)

I didn't check if it is always the same crash but it's repeating (going back to August 2022):

# coredumpctl | fgrep fossilize
[...]
Fri 2023-01-06 22:31:59 CET  4192741 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Fri 2023-01-06 22:34:27 CET  4193721 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Fri 2023-01-06 22:35:26 CET      487 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Fri 2023-01-06 22:36:15 CET      866 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Fri 2023-01-06 22:36:16 CET      863 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Fri 2023-01-06 22:59:47 CET     7791 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Fri 2023-01-06 23:00:35 CET     8399 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Fri 2023-01-06 23:00:36 CET     8397 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Fri 2023-01-06 23:02:06 CET     9014 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 03:39:43 CET    13779 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 03:39:47 CET    13775 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 03:43:19 CET    16516 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 03:43:25 CET    16826 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 03:43:27 CET    16887 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 03:43:28 CET    16852 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 03:43:28 CET    16896 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 06:36:11 CET    66227 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 06:36:14 CET    66247 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 06:36:15 CET    66248 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 06:57:35 CET    73782 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 06:57:46 CET    73818 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 06:58:21 CET    74063 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 06:58:21 CET    74070 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Sat 2023-01-07 06:58:24 CET    74117 500 500 SIGSEGV missing  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                              -
Wed 2023-01-11 10:49:12 CET  3758236 500 500 SIGSEGV present  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                          15.1M
Wed 2023-01-11 10:49:13 CET  3758240 500 500 SIGSEGV present  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                          14.9M
Thu 2023-01-12 18:08:41 CET    21783 500 500 SIGSEGV present  /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay                                          74.3M

Steam crash when launching on Fedora or Nobara

Your system information

Please describe your issue in as much detail as possible:

My provided gist is from my current install of PopOS which has no issues launching Dota 2. I also have no issue when launching from Arch Linux. If necessary I can install Fedora and Nobara and provide a gist.
My issue is that when launching the game from Fedora or Nobara Project the game crashes when processing Vulkan shaders.

Steps for reproducing this issue:

  1. Launch Dota 2 on Fedora or Nobara
  2. Steam starts processing Vulkan shaders
  3. Steam crashes

[Dota2] fossilize eats all RAM and makes the system unresponsive as a result.

Specs:

OS: Gentoo Linux
CPU: i7-9700K
GPU: AMD 5700xt (mesa drivers)
RAM: 16GB

In the new steam beta after every update to Dota2 (doesn't seem to matter how small of an update), fossilize will rebuild the vulkan shaders when launching Dota2.

When it is rebuilding it eats all of my ram (16gb) and makes my computer swap. Making it unresponsive for around 1-2 minutes while it is building the shader cache.

Perhaps there could be some mechanism in place to make sure fossilize doesn't go overboard with memory usage if it will go over the available amount of memory?

I don't know if this is the correct place to report this. Sorry if it is not.

Compiling Vulkan shaders with less than 50% of free memory leads to OOM situation and system freeze

Your system information

  • Steam client version (build number or date): 1689034492
  • Distribution (e.g. Ubuntu): Ubuntu
  • Opted into Steam client beta?: No
  • Have you checked for system updates?: Yes
  • Steam Logs: steam-logs.tar.gz
  • GPU: AMD Radeon RX 5700 XT
  • CPU: AMD Ryzen 7 1700X (8 cores, 16 threads)

Please describe your issue in as much detail as possible:

My system does not have swap configured, which means once the RAM is all occupied the system can't simply use swap to get out of an OOM situation.

What I expect to happen: Steam detects how much memory is available and spawns fossilize_replay processes accordingly so as not to get into an OOM situation, instead of spawning a process for each logical CPU.

What actually happens: Steam spawns the maximum number of fossilize_replay processes it thinks the system supports (in my case, 16 processes). As each process takes up ~512 MB of RAM, this means the system needs at least 8 GB of free RAM. Whenever this is not the case, e.g. because you have other apps open, the system freezes and stops responding. I have tried leaving the system in this state for up to 15 minutes, but the only way to get out of this freeze is to perform a reset (ctrl+alt+printscreen+REISUB).

I have experienced this several times and it is consistently reproduceable.

Steps for reproducing this issue:

  1. On a system with 16 GB of RAM and a 16-threads CPU, as well as no swap configured, open applications until you have more than 8 GB occupied.
  2. Start Vulkan shaders compilation.

fossilize_replay should clear temporary files or fail gracefully

After updating to a new version of fossilze, I started hitting an odd assertion failure down inside rapidjson.

fossilize-replay: ../rapidjson/include/rapidjson/document.h:1218: rapidjson::GenericValue<Encoding, Allocator>& rapidjson::GenericValue<Encoding, Allocator>::operator[](const rapidjson::GenericValue<Encoding, SourceAllocator>&) [with SourceAllocator = rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>; Encoding = rapidjson::UTF8<>; Allocator = rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>]: Assertion `false' failed.

What really confused me is the same version worked fine on the same workload on a different machine. I even rsync'ed the build directory from one to the other to make sure something fishy wasn't happening in the build. Since I was using this on the driver I develop, I assumed the problem was in the driver, and I spent a lot of time digging there first.

After quite a bit of debugging, I found the problem was that subgroup_size was missing from the JSON when parse_json_stats was called. After quite a bit more debugging, I found that subgroup_size existed in all the JSON strings leading to serialization, but it never got out to the file.

After... more time than I care to admit, I found this code in write_entry was returning early:

		auto itr = seen_blobs[tag].find(hash);
                if (itr != end(seen_blobs[tag]))
                        return true;

That was when it finally dawned on me... a stale foo.csv.__tmp.foz file from the old version, that did not have subgroup_size was being read, so the new data was never written out.

At program start up, fossilize_replay should either remove any pre-existing __tmp.foz files or terminate early with a sensible error message.

Report failing pipeline

It is desirable to report which exact pipelines are failing compilation and not just shader modules.
This also applies to non-robust replayer which can log-and-die.
Also, a reproducible command line is desirable so that the failing pipeline can be debugged rapidly.

Layer log messages are too vague

Fossilize layer log messages are too vague. I got this particular error message Fossilize ERROR: Handle is not registered. multiple times today. It would be helpful if it specified which handle is not registered (e.g. pipeline handle, render pass handle...). Even the word registered is too vague - the error message could give a hint why the handle "registration" fails.

Steam keeps crashing when fossilize process "Deus Ex: Human Revolution - Director'cut" shaders

What I see :
Ubuntu 20.04 / Radeon RX 5700 XT / Mesa 20.2.1
Launch Steam in a terminal (I have no other programs running except Gnome System Monitor)
Go to "Shader Pre-Caching" Tab (I have already around 30 GB of shaders already cached)
I can see shader compilation for "Deus Ex: Human Revolution - Director'cut" : it goes steadily from 0% to 99%
then Steam client crash with theses messages (which are fully reproduced each time) :

in the terminal :
OUT OF MEMORY! attempted allocation size: 1681471294 ****

in .steam/error.log :

/data/src/tier0/memstd.cpp (2448) : Fatal Assertion Failed: OUT OF MEMORY
/data/src/tier0/memstd.cpp (2448) : Fatal assert failed: /data/src/tier0/memstd.cpp, line 2448.  Application exiting.

During the shader processing :
3 fossilize-replay are spawned
RAM Usage peaks at 4 GB (+ in Cache 7,5 GB) (Total RAM on this PC : 15,6 GB)
SWAP : not used (8 GB available)
CPU : 3 cores are used at 100% (Total number of cores on this PC : 12 cores)
Free space available for the Steam Library : 74 GB

Screenshot from 2020-11-03 15-01-24

Screenshot from 2020-11-03 15-12-19

The problem is worse than expected : If I try to uncheck ""Allow background processing of Vulkan shaders", then Steam instant crashes with same error messages than above. And when I relaunch Steam ""Allow background processing of Vulkan shaders" is still checked.

Workaround :
I guess the only way to make Steam usable again is to (try to) completely disable Shader Pre-caching or uninstall this game.
I uninstalled "Deus Ex: Human Revolution - Director'cut" and now Steam is processing shaders for others games.

Error spam w/ D9VK on Windows

Hi! When playing A Hat in Time w/ D9VK, I get this error spam

Exception thrown at 0x00007FFFA94B5BF8 in HatinTimeGame.exe: Microsoft C++ exception: Fossilize::Exception at memory location 0x000000001A4CE9E0.

This has only started to happen today for me, not sure what's triggered it but it's happening on old and new builds all of a sudden.

D9VK Build to Reproduce the Issue:
d9vk-master.de80c192c4c1b218df531d383b0d6bda710edf49.zip

Tested Game:
A Hat in Time (253230)

Cheers!

  • Josh ๐Ÿธ

Disable VK_AMD_shader_fragment_mask if descriptor buffers are used in replayer

Hitting this VU now:

Fossilize ERROR: [Layer]: Error: Validation: Validation Error: [ VUID-VkDeviceCreateInfo-None-08095 ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xe6a1c10a | vkCreateDevice(): If the descriptorBuffer feature is enabled, ppEnabledExtensionNames must not contain VK_AMD_shader_fragment_mask. The Vulkan spec states: If descriptorBuffer is enabled, ppEnabledExtensionNames must not contain VK_AMD_shader_fragment_mask (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkDeviceCreateInfo-None-08095)

Pipeline filtering based on actual enabled features

In many scenarios, we end up replaying shaders on devices which were never supposed to see those shaders in the first place. We should have some kind of lightweight validation in place to make sure we don't submit obviously wrong pipelines to a device for compilation which is very likely to crash.

Accumulating many .foz files with Gamescope

So I am running Emulationstation-DE (non-steam game), Resident Evil HD, and Nier Automata all with Gamescope. I have been noticing that every time I start up with gamescope it creates a new .foz file inside of the steamapps/shadercache/fozpipelinesv6 directory. It looks like the way it is creating them is a bug because the hash is the same, but it keeps making copies. Take RE HD for example:

it is executed with gamescope -H 1440 -h 1440 -r 60 -f -- %command%
The Foz files that are created every time look like:
image

With emulationstation-DE, something that's been installed longer than RE HD and has been used quite a bit:
image

Note that for ES-DE the hash changed at some point, this may have been due to me installing new GPU drivers

With Nier its the same situation, a new .foz file everytime I launch the game

All the .foz files are the same size, is this a bug? This only happens when games are executed with gamescope. It does not matter if its a non-steam game or not

Edit: the screenshots are a bit dated now since I originally opened this issue over at ValveSoftware/gamescope#749, but I got no feedback, it might not be a gamescope issue perse, any help would gladly be appreciated

ERROR: Consuming pipeline libraries while creating a pipeline library

Hey, while messing around with the UE5 RT Demo app from HansKristian-Work/vkd3d-proton#1295, I encountered a crash in RADV's shader compiler when the app is run with VKD3D_FEATURE_LEVEL=12_2 VKD3D_CONFIG=dxr11 RADV_PERFTEST=rt.
I wanted to record a fossilize archive to reproduce the crash with FOSSILIZE_DUMP_SYNC=1, but when replaying the generated archive, the compiler crash is not reproduced and I get the following errors:

Fossilize ERROR: Consuming pipeline libraries while creating a pipeline library. This cannot work.
Fossilize WARN: Did not replay blob (tag: 9, hash: 0x046ff16dd2c9efa6). See previous logs for context.
Fossilize ERROR: Consuming pipeline libraries while creating a pipeline library. This cannot work.
Fossilize WARN: Did not replay blob (tag: 9, hash: 0x57ab729c726f4ddd). See previous logs for context.
Fossilize ERROR: Consuming pipeline libraries while creating a pipeline library. This cannot work.
Fossilize WARN: Did not replay blob (tag: 9, hash: 0x046ff16dd2c9efa6). See previous logs for context.
Fossilize ERROR: Consuming pipeline libraries while creating a pipeline library. This cannot work.
Fossilize WARN: Did not replay blob (tag: 9, hash: 0x57ab729c726f4ddd). See previous logs for context.

I'm not sure whether this is a vkd3d-proton or fossilize issue, so reporting it here first.
Relevant foz archive: rttest.d895ec754bd56a9e.2.zip

Installed layer JSON has the wrong path

Doing the standard mkdir build; cd build; cmake ..; make; sudo make install will install /usr/local/share/vulkan/explicit_layer.d/VkLayer_fossilize.json and /usr/local/lib/libVkLayer_fossilize.so, but the json file has "library_path": "libVkLayer_fossilize.so", i.e. it has an incorrect relative path to libVkLayer_fossilize.so, which makes the installed json file useless as-is. This was apparently missed with #47.

VK_KHR_create_renderpass2 raises Fossilize ERROR

Is more a question than a bug (probably), but since I have enabled and used renderpass2, I obtain some fossilize error for my renderpasses handles:

Fossilize ERROR: Render pass handle 0xe706cb000002d9d3 is not registered. It has either not been recorded, or it failed to be recorded earlier.

Am I doing something wrong or is not supported at the moment? Is there a way to silence the error?

[Shadow of the Tomb Raider] fossilize eats all RAM until it OOMs

The symptoms here seem to be the same as #84 but that one was fixed and closed, so I was asked to file a new issue.

In the last month or two, I've noticed that fossilize seems happy to consume all system memory without bounds, and this is particularly evident with Shadow of the Tomb Raider (native Linux version), which consistently sees fossilize gobble up all the memory and then eventually get OOM killed and you have to kick it by turning background processing off and on again. It does eventually complete because it doesn't start from zero each time, but it makes the system unusable for anything else until it finally completes. I've been preemptively turning background processing off and on while watching the memory usage to get it to complete a bit faster, but that's no fun.

I suspect that the behaviour here is not unique to SotTW - it's just that this seems to have enough work to do that it can saturate my system.

System Details:

  • CPU: Core i9-12900K
  • Memory: 64GB (no swap)
  • GPU: Nvidia 515.48.07
  • OS: Ubuntu 22.04 with 5.18.4 mainline kernel
  • Steam Client: Beta 2022-06-18 00:17:34 1655513879

Thanks.

[question] why fossilize running?

When I open steam, it opens fossilize_repla on my machine, it eats about 30% CPU. But when I close steam, it is still running. Why is that? What trigger Fossilize to run? How do fossilize operate? I want to know this because it seems it run on its own,

fossilized_repla freq prevents clean system shutdown/restart

Your system information

  • Steam client version (build number or date): Aug 20 2021, at 20:39:31
  • Distribution (e.g. Ubuntu): Arch (via EndeavourOS)
  • Opted into Steam client beta?: YES
  • Have you checked for system updates?: YES

Please describe your issue in as much detail as possible:

Noticing lately that my system will take a long time to restart or shutdown sometimes because steams fossilized_repla process refuses to terminate or be killed. System just forced to wait until its finished.

https://gist.github.com/jarrard/83901432e10599bab09c96d6ba471f0d

Steps for reproducing this issue:

  1. Restart or Shutdown

Fossilize shaders problem (Batman Arkham Knight)

Your system information

  • Steam client version: Latest beta version October 15
  • Distribution: Pop OS 20.04
  • Opted into Steam client beta?: Yes
  • Have you checked for system updates?: Yes

https://gist.github.com/NikoBellicRU/5935b61d616c0d1a55fcbb3b4bf7c6c0

For some reason the shaders in this game are not working correctly, the .foz file used to be around the same size as the swarm file but now it's not even close, the .foz is like 18mb and swarm 245mb and i noticed right away cause i was having huge stutters and also like 2 weeks ago last i played it was fine so not sure what happen.

Tried deleting the shaders folder / enabling disabling shaders on steam, i always use the mesa oibaf ppa so i tried to remove it to the older mesa and no change also, reinstalled steam, even refreshed my Pop OS install but nothing.

To reproduce just install the game as you would do normally

Screenshot from 2020-10-18 14-19-36
Screenshot from 2020-10-18 14-19-52

Steam leaks fossilize_replay children in stopped state

When Steam crashes (and maybe also when quit normally) while fossilze_replay is running, it may leak fossilize_replay processes in stopped state (as part of the load limiter which SIG_STOPs children). The main process should probably send SIG_CONT to all children before exiting or being forcefully quit.

Install on Windows missing VkLayer_fossilize.json

Install copies the files to:
C:\Program Files (x86)\Fossilize\lib\VkLayer_fossilize.dll
C:\Program Files (x86)\Fossilize\lib\VkLayer_fossilize.lib

The json file, VkLayer_fossilize.json, for the layer is not copied.

vkGetInstanceProcAddr and vkGetDeviceProcAddr return wrong functions

On Linux, when calling your vkGetInstanceProcAddr with vkGetInstanceProcAddr(instance, "vkGetInstanceProcAddr"), instead of returning itself (as it should) it returns the loader's global vkGetInstanceProcAddr (same for vkGetDeviceProcAddr). This in turn can cause layers above you to get incorrect function pointers which can crash the application.

The reason this is happening is that your vkGetInstanceProcAddr function is defined with that exact name and with process global linkage, which means that in line 354 in dispatch.cpp, the symbol 'vkGetInstanceProcAddr' does not refer to your function, but to the process global one.
Because the loader is loaded before your layer, the global function will just be the loader's one instead of yours.

To fix this, I recommend renaming your functions to something like Fossilize_GetInstanceProcAddr and Fossilize_GetDeviceProcAddr, and adding the following field in the .json file inside the "layer" section:

"functions": {
      "vkGetInstanceProcAddr": "Fossilize_GetInstanceProcAddr",
      "vkGetDeviceProcAddr": "Fossilize_GetDeviceProcAddr"
}

Cheers

Use released submodules instead random git snapshots

Hi,

I tried to package Fossilize for Debian, but currently it's not possible because submodules of spirv-* are "random" git versions newer then released versions. Would it be possible to support building against release versions of spirv submodules?

Best,
Dylan

Can go into infinite recursion when combined with libstrangle

While investigating ValveSoftware/steam-runtime#443, I tried running Artifact (a Vulkan game) with the libstrangle frame-rate-limiter module.

One of the failure modes I'm seeing for those looks like either a bug in the Fossilize Vulkan layer, or a bug in some other component that's made worse by how Fossilize's VK_LAYER_fossilize_GetDeviceProcAddr behaves.

Steps to reproduce

Install libstrangle. I used a Debian 11 machine with NVIDIA proprietary graphics, and installed libstrangle into /usr/local with the upstream makefile (make clean && make && sudo make install).

In Steam, set the launch options for a Vulkan game to DISABLE_VK_LAYER_VALVE_steam_overlay_1=1 stranglevk -f 3 %command% (I'm disabling the Steam overlay to reduce the number of moving parts, I get a different segfault if I leave both that and Fossilize enabled).

Set the game to launch in the "Steam Linux Runtime" compatibility tool.

Select the client_beta branches of both "Steam Linux Runtime" and "Steam Linux Runtime - Soldier" (they should be installed automatically, you just need to switch branch). steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt needs to say pressure-vessel 0.20210809.1 or later, which is currently only in the beta; otherwise libstrangle accidentally gets disabled and you won't see the crash.

Launch the game.

Expected result

The game runs, throttled to approximately 3fps.

Actual result

Segmentation fault.

Steps to reproduce, with debugging

As above, but run Steam with PRESSURE_VESSEL_SHELL=instead in the environment. Now, when you launch a game in the container runtime, instead of the actual game you'll get an xterm, in which you can run "$@" to get the actual game.

Instead of "$@", run:

prlimit -s100000 \
gdbserver localhost:12345 \
/usr/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-vulkan --visible

Ideally, before running gdb, set the DEBUGINFOD_URLS environment variable to a space-separated list with a source of detached debug symbols for your host OS (e.g. https://debuginfod.debian.net for Debian), and also debuginfod reading from com.valvesoftware.SteamRuntime.Sdk-amd64,i386-soldier-debug.tar.gz from soldier.

On the host system, run gdb -ex 'target localhost:12345' to connect a remote debugger to the process in the container, and type cont to continue.

Stack trace

The crash seems to be infinite recursion in VK_LAYER_fossilize_GetDeviceProcAddr(), leading to a segfault when stack space runs out. The prlimit -s100000 in my reproducer is to make that happen sooner, so that there are "only" 1750 or so stack frames, rather than tens of thousands.

#0  0x00007ffff7b9829a in vkGetDeviceProcAddr (pName=0x7ffff7baa747 "vkQueueSubmit", device=0x5555558d8e48) at ./loader/trampoline.c:91
#1  vkGetDeviceProcAddr (device=0x5555558d8e48, pName=<optimized out>) at ./vulkan-headers/include/vulkan/vulkan_core.h:3330
#2  0x00007fffeb54e69e in VK_LAYER_fossilize_GetDeviceProcAddr ()
   from target:/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan_imp_layer/libVkLayer_steam_fossilize.so
#3  0x00007fffeb54e69e in VK_LAYER_fossilize_GetDeviceProcAddr ()
   from target:/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan_imp_layer/libVkLayer_steam_fossilize.so
...
#1755 0x00007fffeb54e69e in VK_LAYER_fossilize_GetDeviceProcAddr () from target:/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan_imp_layer/libVkLayer_steam_fossilize.so
#1756 0x00007fffeb54e69e in VK_LAYER_fossilize_GetDeviceProcAddr () from target:/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan_imp_layer/libVkLayer_steam_fossilize.so
#1757 0x00007ffff7b7f363 in loader_init_device_dispatch_table (dev_table=dev_table@entry=0x555555814cb0, gpa=gpa@entry=0x7fffeb54e600 <VK_LAYER_fossilize_GetDeviceProcAddr>, dev=0x5555558d8e48) at ./loader/generated/vk_loader_extensions.c:318
#1758 0x00007ffff7b9272e in loader_create_device_chain (pd=pd@entry=0x5555557f5c40, pCreateInfo=pCreateInfo@entry=0x7fffffffbdd0, pAllocator=pAllocator@entry=0x0, inst=inst@entry=0x55555558e450, dev=dev@entry=0x555555814cb0, callingLayer=callingLayer@entry=0x0, layerNextGDPA=0x0) at ./loader/loader.c:6291
#1759 0x00007ffff7b93559 in loader_layer_create_device (instance=instance@entry=0x0, physicalDevice=physicalDevice@entry=0x5555557f5de0, pCreateInfo=pCreateInfo@entry=0x7fffffffbdd0, pAllocator=pAllocator@entry=0x0, pDevice=pDevice@entry=0x7fffffffbe40, layerGIPA=layerGIPA@entry=0x0, nextGDPA=0x0) at ./loader/loader.c:5838
#1760 0x00007ffff7b9671f in vkCreateDevice (physicalDevice=0x5555557f5de0, pCreateInfo=0x7fffffffbdd0, pAllocator=0x0, pDevice=0x7fffffffbe40) at ./loader/trampoline.c:779
#1761 0x0000555555558949 in ?? ()
#1762 0x0000555555557902 in ?? ()
#1763 0x00007ffff7999d0a in __libc_start_main (main=0x555555557700, argc=1, argv=0x7fffffffc288, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffc278) at ../csu/libc-start.c:308

Does fossilize compute shaders for every graphics card detected ?

Hello,
it is more a question for now (but it could become a feature request)

Does fossilize compute shaders for every graphics card detected ?

I recently plugged a 2nd graphics card (radeon HD 6450) in addition to my main RX 5700 XT (so both are AMD).
(I use this old card only for a few games that are best displayed with the analog VGA output.)

Since that moment, I noticed that steam is computing shaders for games already processed : is it doing the whole library again for the 2nd graphics card ?

If that's the case, it would be nice to have more control and prevent shadercache duplicates.

fosselize_replay eats all RAM when background processing shaders

This seems to happen in multiple games. Latest issue occurs with "Red Dead Redemption 2" as well as "The Elder Scrolls V: Skyrim Special Edition".

Both games, cannot complete shader processing with out eating all system memory.

System Details:

  • Memory: 64GB
  • CPU: i7-13700k
  • GPU: RX 6700 XT.
  • OS : Fedora 37
  • Kernel Version: 6.0.16-300.fc37.x86_64
  • Steam API: V020
  • Steam package version: 1671236931
  • Mesa: 22.3.2

Steam was installed from the rpmfusion.org repo.

The issue looks very similar to #194 , #198 or #84.

Something seems to cause it to not limit memory use. If I watch the memory use and enable/disable processing, you can aid it through this process as it is making progress. It just doesn't complete before it uses all memory.

Happy to help troubleshoot with direction. Haven't found anything particularly helpful in ~/.local/share/Steam/logs/shader_log.txt. Not sure how the manually run fosselize_replay to troubleshoot further.

Can I run fossilize manually?

Fossilize can take a bit of time when I want to start a game.
Is there a way I can stick a call to fossilize into a cron job and have it run in the background regularly?
I tried the naive approach of copying the call from ps, resulting in the following:

~/.local/share/Steam/ubuntu12_64/fossilize_replay \
  ~/.local/share/Steam/steamapps/shadercache/570/fozpipelinesv5/steamapp_pipeline_cache.foz \
  ~/.local/share/Steam/steamapps/shadercache/570/fozpipelinesv5/steam_pipeline_cache.foz \
  --on-disk-validation-whitelist ~/.local/share/Steam/steamapps/shadercache/570/fozpipelinesv5/steam_pipeline_cache_whitelist \
  --replayer-cache ~/.local/share/Steam/steamapps/shadercache/570/fozpipelinesv5/replay_cache \
  --master-process --quiet-slave --shmem-fd 132 --control-fd 145 --spirv-val --num-threads 3 \
  --device-index 0 --timeout-seconds 10 --implicit-whitelist 0
Fossilize INFO: Attempting to map shmem block.
Fossilize INFO: Using control FD as sentinel.
Fossilize ERROR: Failed to add control_fd to epoll.

Is the file descriptor created outside of fossilize? If so can I manually do it?

Fossilize reprocesses the same shaders over and over again (Warframe)

OS: Arch Linux
CPU: 3700X
GPU: GTX 1070 (455.28)
RAM: 16GB

Steam will continually reprocess Warframe shaders. If I let it finish (viewed from Settings - Shader Pre-Caching), start and close the game, it will start processing again. If I restart the system, it will again reprocess the shaders. The only tip I've read to fix this is to change the default game directory to the same that Warframe is installed in. I've done this, however it hasn't changed anything.

Each time this takes around 20-25 minutes, and a not-insignificant amount of memory, as well as unneeded wear on my M.2. Is there a way I can fix this without totally disabling Shader Pre-Caching?

fossilize_replay dumped core

I've lately seen this for the first time:

# dmesg
[101136.441571] fossilize_repla[540674]: segfault at 10 ip 000055cfc73cdd74 sp 00007ffeb8737bb0 error 4 cpu 7 in fossilize_replay[55cfc73a1000+169000]
[101136.441580] Code: 00 48 c7 44 24 58 00 00 00 00 48 8d 8c c8 30 08 00 00 48 8b 80 b0 08 00 00 48 c7 44 24 60 00 00 00 00 c7 44 24 40 11 00 00 00 <48> 8b 78 10 48 8d 05 31 d0 16 00 ff 10 e9 0f ff ff ff 89 c7 e8 93

I'm not sure how to decode this, I'm also seeing a similar dmesg output for Electron apps sometimes. The coredump isn't very helpful either because debug info seems missing:

# sudo coredumpctl info 540674
           PID: 540674 (fossilize_repla)
           UID: 500 (kakra)
           GID: 500 (kakra)
        Signal: 11 (SEGV)
     Timestamp: Sun 2020-12-20 23:32:05 CET (2 days ago)
  Command Line: /home/kakra/.local/share/Steam/ubuntu12_32/../ubuntu12_64/fossilize_replay /home/kakra/.local/share/Steam/steamapps/shadercache/489830/fozpipelinesv4/steamapp_pipeline_cache.foz /home/kakra/.local/share/Steam/steamapps/shadercache/489830/fozpipelinesv4/steam_pipeline_cache.foz --master-process --quiet-slave --shmem-fd 82 --spirv-val --num-threads 2 --on-disk-validation-whitelist /home/kakra/.local/share/Steam/steamapps/shadercache/489830/fozpipelinesv4/steam_pipeline_cache_whitelist --device-index 0 --timeout-seconds 10 --implicit-whitelist 0
    Executable: /home/kakra/.local/share/Steam/ubuntu12_64/fossilize_replay
 Control Group: /user.slice/user-500.slice/[email protected]/app.slice/app-steam-2cad372f130f4fb1b9d86232268f33c5.scope
          Unit: [email protected]
     User Unit: app-steam-2cad372f130f4fb1b9d86232268f33c5.scope
         Slice: user-500.slice
     Owner UID: 500 (kakra)
       Boot ID: 25c3b6c46f9341b4b5d0d292e264aec4
    Machine ID: 121b87ca633e8ac0016656680000001b
      Hostname: jupiter
       Storage: /var/lib/systemd/coredump/core.fossilize_repla.500.25c3b6c46f9341b4b5d0d292e264aec4.540674.1608503525000000.zst
       Message: Process 540674 (fossilize_repla) of user 500 dumped core.

Error 4 probably means user-space was faulting for a non-existing page (PF_USER).

I copied the 489830 cache to my local build and try to reproduce now with this command:

./fossilize-replay 489830/fozpipelinesv4/steamapp_pipeline_cache.foz 489830/fozpipelinesv4/steam_pipeline_cache.foz --spirv-val --on-disk-validation-whitelist 489830/fozpipelinesv4/steam_pipeline_cache_whitelist --device-index 0 --timeout-seconds 10 --implicit-whitelist 0

It resulted in the following log: https://gist.github.com/kakra/0272aa4ca003836750c18e687d6e1bf3

Retry with a debug build?

Fossilize hangs indefinitely consuming CPU when compiling Spyro shaders

Fossilize process hangs indefinitely on shader 2292/3859 (per shader_log.txt) when compiling shaders for steam appid 996580

Reproduction via Steam console:
shader_build 996580 1

Confirmed this on two different Nvidia systems, one running 440.43.01 Vk Dev drivers, other running 440.44 stable drivers.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.