steam-system-information.txt
steam-shader-targeted-logs.tar.gz

Report preparation and verification

This report was investigated, structured, and drafted with the assistance of OpenAI ChatGPT (GPT-6). AI assistance was used to correlate the timestamps, source/target manifest IDs, cache fingerprints and SteamPipe download/reuse counters across Steam launches and a full system reboot.

All quoted log entries and numeric evidence originate from the reporter's actual system. The reporter ran the tests, collected the original Steam logs, and supplied the system information. The AI assistant organized and cross-checked those records; it did not create the measurements. Observations and hypotheses are deliberately separated. Valve's internal depot/chunk data would be required to establish the root cause.

The original Steam log files and filtered chronological extracts are available for verification. I can provide additional targeted information or perform non-destructive diagnostic tests.

Your system information

• Manufacturer / device: Valve, model Galileo; reported form factor: laptop
• Operating system: CachyOS (64-bit)
• Kernel: 7.2.9-1-cachyos-deckify
• Desktop / window manager: Hyprland; X server vendor: X.Org Foundation, release 12401014
• Steam client version (during the October 7–8 reproductions): 1788652215
• Steam Runtime: steam-runtime_1.0.20260714.251828
• Steam client beta participation: Not independently confirmed
• System update status: Not independently confirmed; package versions listed below were captured
• CPU: AMD Custom APU 0932, 4 physical cores / 8 logical processors, reported speed 3501 MHz
• GPU: AMD Custom GPU 0932, RADV VANGOGH; PCI vendor 0x1002, device 0x1435
• Vulkan driver: Mesa RADV (DRIVER_ID_MESA_RADV), Mesa 26.2.4-arch3.1 (from vulkaninfo --summary)
• OpenGL driver reported by Steam: radeonsi, vangogh, ACO, DRM 3.64; OpenGL 4.6 / Mesa 26.2.4-arch3.1 (this is the OpenGL driver label, not a replacement for RADV Vulkan)
• Installed graphics packages:
  • mesa 3:26.2.4-1
  • lib32-mesa 3:26.2.4-1
  • vulkan-radeon 3:26.2.4-1
  • lib32-vulkan-radeon 3:26.2.4-1
• AMDVLK: Not listed in the recorded package query
• RAM: 14,816 MB (as reported by Steam)
• Display: 1920 × 1080, 59 Hz, one monitor
• Storage: Two SSDs (1 TB and 512 GB reported by Steam), approximately 486,336 MB total available disk space; no HDDs
• Locale: Steam UI English, LANG=pl_PL.UTF-8
• Steam installation: Native Linux installation, logs under ~/.local/share/Steam/logs/
• Shader Pre-Caching: Enabled throughout the investigation
• Affected games: Counter-Strike 2 (AppID 730) and Deadlock (AppID 1422450); shader updates were also seen for AppID 1233570

The following variables were not set in the checked user shell: MESA_SHADER_CACHE, MESA_DISK_CACHE, VK_DRIVER_FILES, VK_ICD_FILENAMES, AMD_VULKAN_ICD.

Steam also reported Oculus Quest 3S / Quest 3 controllers through vrlink; no causal relationship with this shader download issue has been established. The reporter can provide the complete Help → System Information output if needed.

Please describe your issue in as much detail as possible:

Summary

Steam frequently offers updated Shader Swarm depots that require hundreds of megabytes to several gigabytes of new download work, sometimes multiple times in one day for CS2 or Deadlock. The local shader cache is not simply lost after restarting Steam:

1. Steam repeatedly reads previously committed shader cache buckets after client restarts and a system reboot.
2. The RADV shader fingerprint and Steam build remain unchanged during the October 8 reproductions.
3. Earlier shader jobs successfully complete and commit (No Error).
4. Steam subsequently receives new target manifest IDs for the same buckets.
5. Some new manifest versions demand 1–2+ GB of downloading. In several RADV-specific cases, SteamPipe reports reuse 0/0 even though a valid source manifest is present.
6. Not every restart causes a shader download. Reboots and Steam starts provide an opportunity to notice new manifest updates, but they do not systematically invalidate all caches.

The question is whether the apparent update frequency, depot contents, and amount of content reuse are expected, or whether Shader Swarm/SteamPipe's packaging or reuse behavior can be improved.

Expected behavior

With Shader Pre-Caching enabled, a previously committed cache should persist across restarts; new shader content should download when required; and locally available matching content should be reused where possible. Multi-gigabyte repeated downloads should ideally be avoided when there is substantial binary overlap between manifest versions. Disabling Shader Pre-Caching or deleting existing cache data is not an acceptable long-term workaround for users who want to use this feature.

Caveat: The difference in total manifest file size is not a measure of binary content difference. Two large files with similar sizes can have widely different chunks. The logs alone cannot prove that SteamPipe has a reuse bug or that a depot changed by only a few megabytes.

Detailed evidence

A. Cache state survives restarts

From October 7 onward, the Vulkan RADV fingerprint remained:

ac3da3d19386ed23d795ff786b3cb33e

Steam build during these experiments: 1788652215.

At 2026-10-08 01:53:12, Steam read the existing CS2 bucket 1718468 with committed manifest 3859892469304694774, then queued manifest 3475375897406708394. Following the full reboot, at 02:06:09, Steam read that latest committed CS2 manifest again, without starting another CS2 shader download during the captured interval.

Likewise, Deadlock bucket 97346758 was read with committed manifest 3692149897922845185 at 02:06:09 after the reboot, immediately before Steam queued a newer target manifest.

This is strong evidence against a simple loss of committed manifest state at startup.

B. CS2 — two substantial shader depot jobs on October 7, 2026

RADV-specific depot:

• AppID 730; bucket 97356888; type RADV/L7:ac3da3d19386ed23d795ff786b3cb33e
• Source manifest: 1268924805956973212 (1,344,114,841 bytes)
• Target manifest: 7410124914884368031 (1,841,901,568 bytes)

[2026-10-07 14:57:00] AppID 730 update started : download 0/1774045520, store 0/0, reuse 0/0, delta 0/0, stage 0/1840590840

Generic Vulkan pipeline depot:

• AppID 730; bucket 1718468; type SteamSwarm/G7:VulkanPipelinesV6
• Source manifest: 3285159316751107691 (6,931,921,964 bytes)
• Target manifest: 3918024091722686802 (6,982,557,486 bytes)

[2026-10-07 14:59:28] AppID 730 update started : download 0/2439987616, store 0/0, reuse 0/3957550792, delta 0/0, stage 0/6982557486

These jobs together reported 4,214,033,136 bytes (~4.21 GB) of download work. Both subsequently completed successfully.

C. CS2 — successive updates to the same pipeline bucket on October 8, 2026

00:41 — bucket 1718468, SteamSwarm/G7:VulkanPipelinesV6:

• Source 3918024091722686802 (6,982,557,486 bytes)
• Target 3859892469304694774 (6,993,569,158 bytes)
• Total file size change: +11,011,672 bytes

[2026-10-08 00:41:03] AppID 730 update started : download 0/1734743536, store 0/0, reuse 0/4670789174, delta 0/0, stage 0/6993569158

01:53 — same bucket, later manifest:

• Source 3859892469304694774 (6,993,569,158 bytes)
• Target 3475375897406708394 (7,005,405,801 bytes)
• Total file size change: +11,836,643 bytes

[2026-10-08 01:53:15] AppID 730 update started : download 0/1867563904, store 0/0, reuse 0/4548458775, delta 0/0, stage 0/7005405801

The two successful updates began approximately 72 minutes apart, with 1.73 GB and 1.87 GB respectively reported as download work. Steam recognized the prior source manifest on both occasions and committed the updates (No Error). It reused several gigabytes locally, but still needed substantial new download work.

D. Deadlock — RADV depot reports zero reuse on October 7

• AppID 1422450; bucket 97346758
• Type RADV/L7:ac3da3d19386ed23d795ff786b3cb33e
• Source 2023404052689673147 (1,407,754,756 bytes)
• Target 3692149897922845185 (1,513,972,333 bytes)

[2026-10-07 11:06:37] AppID 1422450 update started : download 0/1457533392, store 0/0, reuse 0/0, delta 0/0, stage 0/1512661605

The source manifest existed, yet SteamPipe reported ~1.46 GB to download and reuse 0/0. The job completed successfully.

E. Controlled system reboot — October 8, 02:05–02:08

After a full system reboot, Steam started with the same client build and same RADV fingerprint. At 02:06:09, it read previously committed Deadlock manifests, including bucket 97346758, source 3692149897922845185. At 02:06:11, it queued a new manifest for that bucket:

• Source 3692149897922845185 (1,513,972,333 bytes)
• Target 7525172473901808205 (1,762,896,577 bytes)
• Type RADV/L7:ac3da3d19386ed23d795ff786b3cb33e

[2026-10-08 02:06:12] AppID 1422450 update started : download 0/1692225008, store 0/0, reuse 0/0, delta 0/0, stage 0/1761585849

The update completed and committed with No Error at 02:08:23. This is another ~1.69 GB download estimate with zero reported reuse, despite a recognized source manifest and no RADV fingerprint change.

Immediately afterward, Deadlock also updated its generic Vulkan pipeline bucket 2554139:

• Source 7872182619572422017 (1,528,879,009 bytes)
• Target 6387548119495728712 (1,528,948,486 bytes)
• Total manifest size change: +69,477 bytes

[2026-10-08 02:08:25] AppID 1422450 update started : download 0/103172736, store 0/0, reuse 0/1296852417, delta 0/0, stage 0/1528948486

The second update also finished successfully at 02:08:33.

No pruning of buckets associated with the current RADV fingerprint was observed during the captured post-reboot test. CS2's last manifest was preserved and read correctly, but no new CS2 shader update was queued in that interval.

F. An earlier RADV fingerprint transition is separate

The earlier logs show a RADV fingerprint of bcb28f424e9c859b5988553c1d34d0b9. On October 7, Steam used ac3da3d19386ed23d795ff786b3cb33e, pruned obsolete Mesa SF directories and uncommitted older buckets. This historical driver-cache transition may be legitimate; its exact trigger is not independently verified.

The October 8 reproductions happened after that transition, while the current RADV fingerprint and client build were stable. They should not be attributed automatically to driver-induced cache invalidation.

Download/reuse summary

All values are SteamPipe-reported download and reuse byte counts, not independent packet-level network traffic measurements. The rows represent separate logged shader update jobs; suspended/resumed attempts must not be double-counted.

Impact

The update volume consumes bandwidth, delays game readiness, and can lead to additional shader processing work. Multiple games are affected. I want to keep Shader Pre-Caching enabled; disabling the feature or manually deleting shader caches is not a satisfactory fix.

What appears to work correctly

Steam recognizes RADV; the current RADV cache fingerprint is unchanged across the tested restarts/reboot; committed manifest records survive; existing source manifests are recognized; and the investigated jobs generally finish and commit successfully. Not every restart queues a shader update. This evidence is inconsistent with the simplest explanation of wholesale cache deletion or permissions failure at startup.

Suspected areas (hypotheses, not confirmed causes)

• An unusually high frequency of Shader Swarm manifest publication.
• Large binary/chunk changes in generated FOZ or RADV cache files despite small net changes in final size.
• Inefficient content reuse or delta/chunk construction between successive SteamPipe shader depots.
• Legitimate, substantial underlying shader database changes not visible from the client logs.
• A combination of these factors.

I am not claiming that SteamPipe itself is definitively broken. Only Valve-side manifest/chunk comparison can determine whether the observed reuse levels are avoidable.

Questions for Valve engineers

1. For the exact source/target manifest pairs above, what proportion of SteamPipe chunks is identical, and should more local content be reusable?
2. Is reuse 0/0 with a committed RADV source depot expected for these generated FOZ/cache files?
3. Can depot packaging/serialization cause disproportionately large chunk changes between nearby manifest versions?
4. Is the observed frequency of new shader manifest versions expected?
5. Are there useful client-side flags or logs to distinguish unavoidable content changes from inefficient reuse?
6. Could download/reuse efficiency improve without disabling Shader Pre-Caching?

Related reports

• https://github.com/ValveSoftware/steam-for-linux/issues/6546 — repeated shader downloads after restarting Steam.
• https://github.com/ValveSoftware/steam-for-linux/issues/8076 — shader cache downloading/compiling after reboot.
• https://github.com/ValveSoftware/steam-for-linux/issues/10285 — related recurring multi-gigabyte downloads.
• https://github.com/ValveSoftware/Fossilize/issues/312 — related AMD RADV / large Fossilize shader depot problem.

This report specifically documents persistent committed manifests, stable driver identity, subsequent distinct target manifests, and per-depot SteamPipe download/reuse counts. The main issue here is download volume and reuse, not a reported out-of-memory crash.

Steps for reproducing this issue:

1. On CachyOS / AMD Mesa RADV, enable Steam Shader Pre-Caching.
2. Install CS2 (AppID 730) and/or Deadlock (AppID 1422450).
3. Allow all offered shader depot updates to complete and commit with No Error.
4. Record the RADV fingerprint, Steam build, existing bucket IDs and committed manifest IDs from shader_log.txt.
5. Fully exit/relaunch Steam or reboot the system without changing driver packages or shader settings.
6. Inspect shader_log.txt for Read committed bucket, Source manifest, Target manifest, and new Queuing depot manifest entries.
7. Inspect content_log.txt for the corresponding AppID ... update started entries and their download, reuse, delta, and stage counters.
8. If no new target manifest is offered immediately, check again after later normal launches. A restart does not always cause the problem; the observed trigger is the availability of a new manifest.

The October 8 log evidence includes one successful post-reboot reproduction with Deadlock while CS2's committed depot was preserved.

Attachments

Original and rotated shader/download logs:

• shader_log.previous.txt
• shader_log.txt
• content_log.previous.txt
• content_log.txt

Chronological diagnostic extracts:

• steam-shader-report.txt
• steam-shader-report-after-reboot.txt

The filtered extracts are indexes only, not a substitute for raw logs. I can provide the complete Steam Help → System Information output separately if requested.

For privacy, I prefer attaching only the relevant shader/download logs rather than all Steam logs (which also contain connection, VR, controller, and UI diagnostics). Sensitive local paths/account identifiers may be redacted, without modifying the manifest IDs or diagnostic byte counts.

steam-system-information.txt
steam-shader-targeted-logs.tar.gz