06:49q4a: I tested traces from issue 7452: AHiT_d3d9.trace_TGSI_151222.tar.gz - look fine with OpenGL render and show gray screen with Nine render. AHatinTime_r600_d3d9.trace.tar.gz (12.09.2022) - look fine with OpenGL and Nine.
06:50q4a: I didn't get a lot of ram usage anywhere.
06:58q4a: adavy: I'm also interested, is there example of "default the option for an exe that match its name"?
07:19q4a: Also I'm interested, if it's affected to other games? "A Hat in Time" has option "Precache Shaders" - are you sure that Nine should ignore it and compile shader during gameplay when it's enabled?
16:51adavy: well that precache shader might be one of the reason of this mess in the first place
16:51adavy: I assume precache means precompile everything
16:51adavy: other games are affected
16:52adavy: for example I think some final fantasy was affected
16:54adavy: q4a: see src/util/00-mesa-defaults.conf
16:54adavy: somehow I don't see any nine there, but there was in the past
16:55adavy: q4a: See commit 91755300ece3a67194270db636e6e8c3252fa8f7
16:55adavy: which removed last nine entry there
16:55adavy: but at least you can see how it was done
16:57adavy: you can look in the list of opened or close but on ixit (mesa or wine standalone) for bug reports with keywork such as virtual memory, out of memory, etc
16:58adavy: *closed bug
16:58adavy: q4a: should I understand you have a working patch ?
17:00q4a: no) I like to have testing example before starting write code.
17:02adavy: I think with the GALLIUM_HUD there is a way to show the virtual ram
17:04adavy: hum maybe not. Possibly I debugged the issue by cheating (adding some regular printf in nine at each allocation that would sum all what was allocated for textures, shaders, etc
17:05adavy: Basically, at least on radeonsi, when you compile a nir shader, it gets into several levels of internal cache into a non-optimized format that takes a lot of space
17:05adavy: when you load the shader from the disk cache, you get lower usage
17:06adavy: I think when I debugged the issue, I managed to have one of the cache level get skipped for nine
17:07adavy: The way you should work on this bug report I think is simply erase the disk cache between each run. Using a new recompiled version of mesa also invalidates the disk cache
17:07adavy: when you load the trace, it will have some phases with nothing happening except compilation for many seconds
17:07adavy: with your patch these parts will be almost instantaneous
17:09adavy: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2931
17:14q4a: there is few fixes:
17:14q4a: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4980
17:14q4a: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9578
17:15q4a: last one looks interesting - "radeonsi: Limit the size of the in-memory shader cache". So I will not use too much ram in radeonsi ?1
17:20q4a: adavy: I'm interested: you got this graphs when run games or apitraces of games? https://gitlab.freedesktop.org/mesa/mesa/-/issues/2931#note_496835
17:21adavy: trace
17:22adavy: q4a: I got the situation better (I'm the author of the patches), so the trace would run
17:22adavy: but after long gameplay apparently you can still hit issues
17:31adavy: q4a: on radeonsi you have the live cache, the memory cache and the disk cache
17:31adavy: the live cache is just if you have several instances of exactly the same compiled shader
17:32adavy: the memory cache I think is for shaders which end up the same after optimizing the nir
17:33adavy: the disk cache is the disk version. But somehow when you write it, it takes more memory
17:33adavy: More or less that
17:34adavy: btw you can definitely add d3dretrace.exe to the list of exceptions, as when you play a trace you are not interested in the shader being compiled as you end up running only a subset