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