00:14axdoomer: Where do I report bugs for nouveau? I got a null pointer dereference inside "nvkm_vmm_put_locked".
00:39gnarface: axdoomer: check your distro, or somewhere on freedesktop.org
00:39gnarface: (i think)
00:39axdoomer: ok, thank you!
11:00cyberpear: is that actually useful, or just hype?
11:05prOMiNd: depends what you consider useful
11:09pmoreau: cyberpear: It is just the new location for the documentation NVIDIA publishes, and replaces http://download.nvidia.com/open-gpu-doc/.
11:10pmoreau: Most of the information found in those had already been RE’ed, but some bits where helpful like some hardware-specific workarounds, some of the newly-released MMU bits and I believe some VBIOS bits too.
13:14RSpliet: pmoreau: Yesterday they pushed some docs on the Volta memory system
13:15pmoreau: Yesterday as in 9 days ago? :-)
13:16pmoreau: That’s what I was referring to by “newly-released MMU bits”
13:17RSpliet: Oh heh
13:17RSpliet: I only got the message yesterday
13:18pmoreau: GitHub might have dorked.
13:18RSpliet: Nah, I get my news from Phoronix
13:28pmoreau: It’s just that NVIDIA pinged him yesterday about it. I assume they wanted to advertise the repo a bit more, as quite a few people missed it.
13:28pmoreau: I wonder why they only pinged him yesterday though: are they planning some bigger release soon?
13:31RSpliet: I don't even know who did the pinging in the first place :_D
13:34pmoreau: NVIDIA: “I was emailed from NVIDIA in alerting me to this new effort they are ready to announce”
13:34tomeu: pmoreau, kherbst: got an error compiling this opencl kernel, how do I get more info on where the problem is? http://paste.debian.net/1094963/
13:34kherbst: tomeu: looks like a validation issue
13:35kherbst: tomeu: but you won't get far yet anyway as we still can't accept unstructured spirv and spirv_to_nir will just fail later on
13:35pmoreau: Either spirv-val does not know about the instruction defining %arrayidx78, or SPIRV-LLVM-Translator messed up.
13:35kherbst: I have a branch where I am taking care of that... but.. it's a bit complicated to get right
13:36kherbst: tomeu: you can dumb the spirv
13:36kherbst: with the CLOVER_DEBUG stuff
13:37tomeu: with MESA_SPIRV_FAIL_DUMP_PATH?
13:37pmoreau: tomeu: CLOVER_DEBUG=spirv CLOVER_DEBUG_FILE=somefile
13:39tomeu: got it
13:39tomeu: appended it to the end of http://paste.debian.net/1094967/
13:40kherbst: it gets defined later
13:40pmoreau: Yeah, it looks messed up
13:41kherbst: doesn't have to be
13:41kherbst: if 91 is always defined following the tree, then it's fine
13:41kherbst: most likely it's not the case
13:41kherbst: but it could be
13:41kherbst: tomeu: push it through spirv-cfg
13:43tomeu: kherbst: hmm, does that expect the spirv to be serialized?
13:43tomeu: I get:
13:43tomeu: error: file size should be a multiple of 4; file '/tmp/fail.spirv.spvasm' corrupt
13:43kherbst: use spirv-as
13:43kherbst: pmoreau: from the cfg it seems to be correct
13:44pmoreau: I am not sure SPIR-V allows that though.
13:44kherbst: I think there isn't much of a choice
13:45kherbst: I don't think you can actually require SSA form _and_ order of the blocks
13:45kherbst: or maybe...
13:45pmoreau: Time to go through the spec
13:46kherbst: anyway, it sounds like a silly requierment because it makes compilers more complex with 0 benefit
13:47kherbst: tomeu: your spirv-tools seems to be quite old
13:47kherbst: ohh wait
13:47kherbst: what's that?
13:47kherbst: it looks weird
13:48kherbst: it was my fault
13:48kherbst: no, it looks correct
13:49kherbst: if_Then81 is where the consumer of 91 is
13:49kherbst: and 91 is defined in if_end71_1
13:49tomeu: kherbst: regarding unstructured, do you still think this is the right approach? https://gitlab.freedesktop.org/karolherbst/mesa/commits/nouveau_nir_spirv_opencl_unstructured
13:49kherbst: it's not approach
13:49kherbst: that's the biggest issue with it
13:50kherbst: I mean.. it works with simply shaders
13:50kherbst: but that's mainly me just figuring stuff out on my own
13:50kherbst: we should actually base it on some real papers or real algorithms
13:50kherbst: the spirv parts are fine though
13:50kherbst: the nir pass isn't
13:51tomeu: guess the theory isn't that different from what llvm's structurize pass does?
13:51kherbst: tomeu: also, that pass makes the assumption that the generated spirv is already more or less structured
13:51kherbst: it just searches for if and loop patterns
13:51pmoreau: “The definition of an SSA <id> should dominate all uses of it” (except for function calls and phi nodes)
13:51kherbst: and creates the nir_loop and nir_if constructs out of it
13:51pmoreau: So it is no valid
13:51kherbst: it doesn't actually structurize
13:52kherbst: pmoreau: it does dominate them
13:52kherbst: why do you think it doesn't dominate them?
13:53kherbst: again.. this isn't an issue about the value being defined later in the CFG
13:53kherbst: that the block is just placed later
13:53kherbst: in the spirv
13:53kherbst: not in the CFG
13:53pmoreau: It does, my bad
13:54kherbst: tomeu: actually.. I think my code would even be able to consume that spirv...
13:54kherbst: we need a proper pass here
13:54kherbst: and I like the idea of having a structurizer + a goto_if lowering pass
13:54kherbst: but yeah...
13:54kherbst: the first one is a pain
13:54kherbst: and we might not even need it
13:55kherbst: no idea how crazy you can go with goto in clang and how much of it is required by CL
13:57kherbst: tomeu: the biggest issue with the llvm structurizer was, that it didn't allow us to generate a structured spirv conforming to the spirv spec :/
13:57kherbst: so it still needed some silly fixup
13:57kherbst: but that doesn't help with getting spirvs as input anyway
13:57kherbst: but the reqs seem to differ between what the llvm struzturizer produce and what spirv requiers
13:58kherbst: tomeu: would be cool though if somebody is willing to look into all of that, as I have other bugs I care more about right now.. like the nouveau MT issues :(
13:59tomeu: hehe, that seems to be a bit more urgent :)
14:00kherbst: anyway.. the spirv bits are already done on the branch
14:00kherbst: so that's already something
14:00kherbst: and I think it's more or less complete
14:00kherbst: only OpSwitch has to be handled
14:00kherbst: I think
14:00tomeu: ok, so I guess for now it would make sense to continue what you were doing in that branch, and reevaluate later
14:00tomeu: possibly using https://llvm.org/doxygen/StructurizeCFG_8cpp_source.html for inspiration
14:00kherbst: well, the best idea would be to just replace the nir pass with something actually working
14:02tomeu: ok, I will play further with this, and maybe wither me or somebody else at collabora could give it a proper look in the future
14:02kherbst: I am quite sure that the only issues I was running into was at the nir level
14:02kherbst: and the spirv_to_nir path was okay
14:03kherbst: tomeu: sounds good
14:03kherbst: tomeu: alternative approach would be to write a spirv structurizer
14:03kherbst: which might be even usefull outside of mesa
14:04kherbst: and put it into spirv-opt or so
15:04kherbst: uff.. found a bug inside librm
15:11kherbst: skeggsb: is nouveau_pushbuf_space expected to mess up the GPU when the pushbuf is empty?
15:11kherbst: or well.. "empty" as in
15:11kherbst: no new commands since the last kick
15:12kherbst: or maybe that's just a mesa issue as the kick_notify callback is called
15:12kherbst: but there is no updated sequence nummber because no fences...
15:12kherbst: yeah.. I think it is actually that