08:13 Venemo: orbea: thanks, I'd appreciate if you could try. it is currently not installed on my workstation but if you still see issues I will give it another look next week.
08:13 Venemo: this week, unfortunately I already have too much on my plate
14:58 orbea: im updating to wine-5.0 now so hopefully I'll get around to testing by the weekend.
17:16 orbea: Venemo: mannerov: nope, not fixed
17:16 orbea: i killed it after it started filling my swap (xram)
17:19 orbea: s/xram/zram/
17:20 Venemo: sorry to hear that
19:12 mannerov: orbea: that sucks
19:12 mannerov: I don't remember what we had found so far
19:13 mannerov: to explain the issue
19:34 mannerov: I can't seem to find a trace with hat or time in the name on my pc... I must have lost it somehow
19:40 mannerov: which trace would you advise to reproduce the issue the fastest ?
19:40 mannerov: also interesting question is if the issue is there for other nir drivers than radeonsi
19:43 orbea: im not sure anyone tried other drivers
19:43 orbea: Venemo: might know better
19:44 mannerov: Venemo: which other drivers have nir ?
19:45 mannerov: orbea: Did you upload a trace or something that reproduces the issue ?
19:45 mannerov: Maybe I used some from another bug report
19:46 orbea: i dont think so, but I dont recall now apitrace failed to work or if I just never did it
19:47 orbea:finds the apitrace instructions
19:47 mannerov: what other game are triggering this ?
19:48 mannerov: Basically I guess we need to understand what is the pattern causing this
19:48 mannerov: and then we can write a simple program
19:48 mannerov: or use the trace that triggers the fastest
19:48 Venemo: mannerov: the working theory is that the IR is used as a shader cache key by radeonsi, and thus it never gets completely freed
19:50 mannerov: err
19:50 mannerov: the entire IR as shader cache key ?
19:50 mannerov: does it do the same with TGSI ?
19:50 mannerov: Maybe that's less an issue because TGSI is short
19:50 mannerov: so maybe somehow the nir is very long for the shaders of this game
19:52 mannerov: Venemo: I guess if the problem is there, we can tune that behaviour for 32 bits system, or just nine
19:53 mannerov: using only hdd cache, rather than the ram one
19:53 Venemo: the solution is for radeonsi to use a hash of the IR as a key, not the full IR
19:54 orbea: remind me, do I want the mingw or msvc apitrace with d3d9?
19:54 Venemo: Marek had a prototype branch that did this somewhere, but I never got around to looking into it deeper than this
19:56 mannerov: orbea: msvc
19:57 mannerov: Venemo: there are two things, the key and the hash of the key, right ?
19:57 mannerov: if the hash matches you compare the key
19:58 mannerov: it's just that for gallium nine I don't think we need to cache the IR in ram
19:58 mannerov: it's useful to reload from hdd
19:58 mannerov: but ram no. Shaders won't be created several times with the same code
19:59 mannerov: so probably that feature should just be scrapped for 32 bits because it eats memory
19:59 mannerov: it's not just the key
20:02 orbea: hat in time is a 64-bit game btw
20:03 mannerov: ah
20:03 mannerov: is it ok running under wine ?
20:03 mannerov: and if yes, any idea why ?
20:04 orbea: it works with wined3d, but a bit slow
20:07 mannerov: so they don't have the nir problem
20:07 mannerov: Venemo: any idea why ?
20:07 mannerov: the game probably uses the same number of shaders
20:07 mannerov: maybe one difference is the fact ogl compiles on first use and we compile before
20:08 orbea: the trace reproduces it, I'll upload it in a moment
20:09 orbea: with nine it hangs upon starting and eats all my ram, with wined3d the trace replays fine
20:11 mannerov: there must be some radeonsi R600_DEBUG option to disable cache
20:24 orbea: mannerov: here is a trace http://slackless.raccoons.tech/trace/HatinTimeGame.trace.xz
20:29 mannerov: thanks
20:42 mannerov: orbea: did you take the trace with wine ?
20:43 Venemo: mannerov: I don't know any more about it than what I said. :( sorry
20:48 mannerov: the long wait for the apitrace to start is unbearable
20:49 mannerov: We need an option to compile only when needed
20:49 mannerov: I don't understand why is it so slow
20:49 mannerov: maybe nir optimizations ?
20:49 mannerov: Venemo: do you cache nir ?
20:50 mannerov: radeonsi caches tgsi to llvm
20:50 mannerov: if tgsi to nir is so slow, we need the same
20:50 mannerov: hdd cache
20:50 mannerov: not ram
20:52 Venemo: no, I don't. radeonsi does
20:53 mannerov: Venemo: I meant tgsi to nir
20:54 mannerov: oh, you mean radeonsi does have ttn integrated with cache ?
21:05 mannerov: anyway, if nir and shaders take non negligible amount of space then I need to implement that compile-only-on-use option. Maybe even release unused shaders when they are not used anymore
21:06 mannerov: if there was a way to know the same taken by a given shader it would be useful to add to the debug info. Not sure we have that
21:06 mannerov: *the space taken
21:09 mannerov: though I would assume the IR can stay on GPU and maybe we do not store it on CPU. Venemo since you work on shaders you may know that
21:28 orbea: mannerov: yes, I took the trace with wine-5.0
21:28 orbea: https://github.com/apitrace/apitrace/wiki/WINE
21:29 orbea: using wined3d
21:31 orbea: when repliaying the trace with wined3d no issues, when replaying it with nine it just hangs and eats my ram
21:38 Venemo: mannerov: no. tgsi to nir doesn't have a cache, neither does nine have a tgsi to nir cache, nor does radeonsi.
21:38 mannerov: Venemo: ok, I guess we can add that to the todo list
21:39 Venemo: mannerov: what radeonsi does is cache the compiled shader (ie. the GCN assembly), and uses the NIR as key to that cache.
21:40 Venemo: so if it gets the same NIR twice it doesn't need to recompile
21:40 Venemo: that's all it does
21:40 Venemo: this is the place where I said that a hash would better to use as a key
21:41 Venemo: would be* better
21:41 mannerov: I think for tgsi it was caching the llvm
21:42 Venemo: I think it used the tgsi itself, and that's why it still uses the IR
21:42 Venemo: on the other hand if nine really does compile an obscene amount of shaders in that game ahead of time, that could be a problem too
21:43 Venemo: there could be a limit to how many are allowed
21:57 mannerov: well we compile what the game asks
21:57 mannerov: the thing is
21:57 mannerov: because of shader variants
21:57 mannerov: maybe we never ever use the version we compile (the default variant)
22:01 Venemo: yeah