valvesoftware / fossilize Goto Github PK
View Code? Open in Web Editor NEWA serialization format for various persistent Vulkan object types.
License: MIT License
A serialization format for various persistent Vulkan object types.
License: MIT License
Will an environment variable like this work?
What is the default log level?
FOSSILIZE_API_DEFAULT_LOG_LEVEL=warning
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
If I record a fossil on a device that supports shaderDeviceClock, the fossil should be skipped if the target device doesn't support the same feature.
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.
# 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
Obsolete and confusing.
[ 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
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
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.
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:
With emulationstation-DE, something that's been installed longer than RE HD and has been used quite a bit:
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
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!
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;
}
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?
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.
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?
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
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.
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.
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,
Steam
-> Help
-> System Information
) in a gist:
* 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.
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."
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.
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.
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?
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?
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.
As in https://gitlab.freedesktop.org/zmike/mesa/-/issues/86, this game crashes in the fossilize layer when quitting. There are no validation issues, so I'm assuming this is a bug in the layer.
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)
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.
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
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
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.
It's somewhat useful to be able to create a FOZ archive directly from shaders since we can get quick ISA feedback that way. Pipeline layouts and render passes can be deduced from reflection.
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.
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.
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.
The game runs, throttled to approximately 3fps.
Segmentation fault.
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.
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
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
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.
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
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.
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?
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:
Thanks.
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_STOP
s children). The main process should probably send SIG_CONT
to all children before exiting or being forcefully quit.
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.
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.
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:
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.
Steam
-> Help
-> System Information
) in a gist: https://gist.github.com/lennie420/a113ee94c69294b7d4ec059e0deea50dMy 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.
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 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
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
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.
On step 3 shader compilation is quick
On step 6 shader compilation can freeze the system
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
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.
This is a fantastic piece of technology however, and thank you to everyone at Valve for maintaining it.
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.