15:25karolherbst: Mark was working on a nouveau shader cache now and it's close to being able to get reviews \o/ 3m (no cache) -> 1m (glsl/tgsi cache) -> 20s (codegen cache)
15:25karolherbst: (shader db run)
15:46imirkin: shouldn't be too big of a change to the internals
15:46imirkin: just have to be careful to serialize the fixups
15:46imirkin: (and relocs)
15:51karolherbst: piglit shows 40 regressions (out of 26k) so it's not all that bad ;)
15:51karolherbst: but I think proper testing will be crucial here.
15:52karolherbst: imirkin: wondering if we should have a seperate variable for the nouveau cache, so a user can turn of the nouveau one, but still keep the glsl/tgsi cache?
15:56imirkin: i suspect i should be able to point out any bugs with review ... it's pretty clear in my mind how it has to work
15:57imirkin: there are a few pitfalls
15:57imirkin: which should be easy to spot
15:58karolherbst: I mean, in the end all of that is indeed pretty straightforward, just some annoying bits (like void* cases, or func pointers)
16:00imirkin: just have to be careful with fixups
16:00imirkin: and saving off all the appropriate bits of state
16:01imirkin: i don't think it's very difficult, but if you forget about one piece, then trouble-lies-ahead
16:01imirkin: actually it might even be that you don't need fixups if you're just going to back to regenerating from TGSI. you just have to have the right state.
16:02imirkin: but it adds a "state" where you have the binary but not the pre-binary + reloc/fixup data
16:05karolherbst: mhh, I think the deeper issue is just that stuff happens inside codegen somewhere, and I'd prefer to make the cut around nv50_ir_generate_code
16:05imirkin: i forget what that does
16:05imirkin: is that the thing that creates the super-final binary with everything applied?
16:06karolherbst: no, it's just doing the compilation
16:06imirkin: oh, perfect
16:06karolherbst: so right now the fixup and relocs get serialized and deserialized
16:06karolherbst: so all of that should just work
16:07karolherbst: next step I think would be to get it working for nv50 as well, as right now it's only tested on nvc0... and we actually hit this spilling memory corruption bug on kepler...
16:07karolherbst: and it got more likely with the codegen cache enabled...
16:08karolherbst: so... I think we have to fix that as well
16:08karolherbst: but the address sanatizer is able to detect that one and we have a few shaders in our shader db hitting it
16:08imirkin: er what?
16:08karolherbst: if the first try fails and we do the second round of RA
16:08imirkin: spilling memory corruption?
16:09imirkin: oh yeah, there's bugs in there =/
16:09imirkin: we undo wrong
16:09imirkin: i stared at it for a long time
16:09imirkin: i think i determined the problem
16:09imirkin: but couldn't come up with a fix
16:09karolherbst: the one thing which happens is, that the spiller removes instructions
16:09imirkin: and then i blinked
16:09imirkin: and it all went away :)
16:09karolherbst: and the value is still referenced
16:09imirkin: right, but in theory that totally can't happen
16:09karolherbst: so we have a use after free
16:10imirkin: the reason that it does happen is the stupid joining of uses
16:10imirkin: or defs rather
16:10karolherbst: I didn't look into it deeper
16:10karolherbst: oh that reminds me.. the other RA bug...
19:40RSpliet: Oh there's two?
19:43karolherbst: RSpliet: just two
19:43karolherbst: I am sure there are at least 10 :p
22:17karolherbst: libasan is awesome...
22:18karolherbst: you can even break on an memory error
22:18karolherbst: and just debug from there
22:19Lyude: karolherbst: is this some neat new alternative to valgrind?
22:19Lyude: oh sweet
22:20karolherbst: it's _fast_
22:20karolherbst: you just enable it with "meson configure -Db_sanitize=address" eg
22:20karolherbst: recompile your stuff
22:24karolherbst: Lyude: https://gist.githubusercontent.com/karolherbst/1b8e32e025178eae2d054151855ee59d/raw/88fa54eb8e2c89c7010503c592d1ee92d4425879/gistfile1.txt
22:24karolherbst: just look at that...
22:25karolherbst: that's how I always wanted to debug those super hard to track down issues
22:37karolherbst: imirkin: ehh.. okay, so that value has 5 defs...
22:48karolherbst: why do we fill those values with so many crap defs
23:12karolherbst: now that mesa requires c++14 we might want to clean up some codegen pre c++11 stuff :D