00:04 imirkin: karolherbst: hm, well that's right - GL_QUAD is only valid in compat
11:19 karolherbst: imirkin: ehh. I think the random error is some state stuck in the compute parts.. at least when the error happens we launched some compute work at least... mhhh
11:22 karolherbst: also.. why aren't we already pushing the pb when glDispatchCompute gets invoked
11:22 karolherbst: sounds like a perf issue potentially
13:24 karolherbst: imirkin: mhhh any idea how to deal with unmapped pbs in depushbuf? I am getting parsing errors due to that obviously :)
13:25 karolherbst: or should we map the bo in libdrm when printing?
13:25 karolherbst: I have no idea why the bo wasn't mapped tbh
13:54 imirkin: karolherbst: it's an expected condition, fix your parser
13:54 imirkin: we don't kick on compute dispatch just like we don't kick on draw
13:55 karolherbst: I know it's expected, but there still might be relevant stuff in them
13:56 imirkin: you'll never know! :)
13:56 karolherbst: why can't I just map those bos?
13:56 imirkin: you can't map them, they're not ready to be read from
13:56 karolherbst: ehh :/
13:56 imirkin: mapping them will cause flushes/stalls/etc, which can't really be done from inside the submit logic
13:57 karolherbst: well.. I only want to map them when the pb gets printed
13:58 imirkin: which is called from within the submit logic :p
13:58 imirkin: anyways, we never do anything too crazy
13:58 imirkin: it's always just data
13:58 imirkin: there would never be BO references, nor new commands
13:59 imirkin: so just make your parser deal with it
13:59 karolherbst: those unmapped ones are indeed super small
14:00 imirkin: not always, it could be elements in a bo on nv50 iirc, which could be sizable
14:00 karolherbst: mhh, I see
14:00 imirkin: but still just data
14:01 karolherbst: still annoying to deal with it as I can't just simply parse the file and iterate over an array :/
14:01 imirkin: can add a (unmapped) thing
14:01 imirkin: to help your parser out
14:02 karolherbst: already did
14:02 karolherbst: I still need to save the location
14:02 karolherbst: mhh
14:02 karolherbst: I could also get rid of the preparsing
14:03 karolherbst: with a 15GB dumb my parser consumes quite a lot of memory actually
14:04 karolherbst: and that realloc sucks anyway
14:17 karolherbst: yay " 1 file changed, 25 insertions(+), 44 deletions(-)" it got simplier indeed
14:34 karolherbst: "nouveau: ch2: psh (unmapped) 00000003 000000015c 000080016c" is what I will print probably
14:35 karolherbst: and then the parser will print this: https://gist.githubusercontent.com/karolherbst/917dd432da7776364c884eea3db42235/raw/f94f13e381808f022c3e421223f9954bfb388515/gistfile1.txt
14:38 imirkin: should say how many words
14:38 imirkin: also make sure this doesn't mess up later parsing. i guess we don't have super-funny situations, so you can sorta assume the next thing will be a new command
14:38 karolherbst: yeah
14:38 karolherbst: I already do that
14:38 imirkin: it's not a valid assumption generically
14:39 imirkin: but it might be valid for nouveau
14:39 karolherbst: mhhh
14:39 karolherbst: yeah.. but then my parser will complain because it can't decode the header
14:39 karolherbst: hopefully
14:39 imirkin: ;)
14:39 imirkin: or it'll decode the header based on bogus data, and fireworks!
14:39 karolherbst: well I am getting this again "unknown mode 0" :D
14:40 karolherbst: imirkin: btw, mind if I push this directly? https://github.com/karolherbst/envytools/commit/313ef0fa74a7ade45975c01f248c85f0f9dc32d3
14:41 karolherbst: there is still an error in bin2dedma
14:41 karolherbst: but...
14:41 karolherbst: ufff
14:41 karolherbst: mmt_txt_nv_state getting redefined
14:41 karolherbst: but mmt_txt_nv_state...
14:41 karolherbst: ahh screw it
14:41 karolherbst: I just fix it like it's already broken
14:43 karolherbst: https://github.com/karolherbst/envytools/commit/3be1a81f37837580adbef0c9c20dcdbdcef0d51e
14:43 karolherbst: just wondering how one can think this is even remotely a good idea
14:43 karolherbst: how maybe I am missing some super obscure C feature
14:54 imirkin: karolherbst: go for it
14:56 karolherbst: ahh.. I indeed hit the issue that the header is 0 after an unmapped pb :/
14:57 imirkin: ok, so we probably do stuff somewhere, in queries or something
14:57 imirkin: i forget exactly
14:57 imirkin: i do think we throw a 4-byte value in the middle of things randomly though :)
14:57 karolherbst: just making sure it's actually the case and not something dumb like EOF
14:57 imirkin: check like ... nvc0_query_hw
14:57 imirkin: look for nouveau_pushbuf_data
14:58 imirkin: iirc it's done as part of DrawTransformFeedback impl
14:58 imirkin: to wait on the query
14:58 karolherbst: nouveau: ch2: psh (unmapped) 00000004 0000000000 000080000c
14:58 karolherbst: nouveau: ch2: psh 00000000 0000002af4 0000002c44
14:58 karolherbst: nouveau: 0x00000000
14:58 karolherbst: :/
14:59 karolherbst: yeah.. the command before something like this is GP104_COMPUTE.UPLOAD.EXEC
15:01 karolherbst: and there is indeed query stuff before that
15:04 karolherbst: oh well
15:04 karolherbst: no idea on how to handle that except skipping until the next value has some of the higher bits set indicating a command :/
15:04 imirkin: hm?
15:04 karolherbst: this sucks a bit
15:04 imirkin: should be easy, no?
15:04 karolherbst: well
15:05 karolherbst: could be data
15:05 karolherbst: instead of a header
15:05 imirkin: not that
15:05 imirkin: doing it properly
15:05 karolherbst: howso?
15:05 karolherbst: I don't know when the next header will come
15:05 imirkin: well, you see a BEGIN for 5 words
15:05 imirkin: you see 3 words
15:05 imirkin: then you see a pushbuf for 4 bytes
15:05 imirkin: then you know that you're "owed" one more word
15:05 karolherbst: what if it's around 200 bytes like in the example ?
15:06 imirkin: doesn't matter
15:06 imirkin: in the example you pasted it's 4 bytes btw (aka 1 word)
15:07 imirkin: and yeah, the indirect buffer could have commands of its own, in which case you're screwed. but we never do that in nouveau.
15:08 karolherbst: mhhh, okay
15:08 karolherbst: so yeah.. in this case it would work: https://gist.githubusercontent.com/karolherbst/077e8c8ea9be41816e96bcde610f2375/raw/54acf46faba8db895a0ff7289ed3c83bad8ce638/gistfile1.txt
15:08 karolherbst: command has 10 values
15:09 karolherbst: 4 missing
15:09 karolherbst: and 6 are there around the unmapped pb
15:09 karolherbst: ehh
15:09 karolherbst: 9 and 3
15:43 karolherbst: okay.. let's see if I can finally parse the entire pb dump :)
16:02 karolherbst: scanf is just so frigging slow :(
16:17 karolherbst: imirkin: btw, I see this 0x5400000 value in uploaded data
16:18 karolherbst: https://gist.githubusercontent.com/karolherbst/112f0f7a6307a5b94034b1594c6eda34/raw/4811a4d2743289656287ab910e24045b27d24d8f/gistfile1.txt is this the launch descriptor or could it be something else?
16:21 karolherbst: actually.. the decs is not big enough
16:24 pmoreau: karolherbst: clover_support_hmm_wip is your branch I should be testing things on if I want improved SPIR-V -> NIR, right? And it doesn't look like you have any of my cl_khr_il_program patches on that one, correct?
16:24 karolherbst: pmoreau: correct
16:24 pmoreau: Ok
16:24 pmoreau: Thank you
17:29 pmoreau: Figured out what was causing an issue: the SPIR-V binaries in the CTS are still using UniformConstant as storage class for BuiltIn variables.
17:30 pmoreau: But there is an open issue against the spec to clarify which storage class should be used, since there was some confusion with SYCL also switching to Input for the BuiltIn. Hopefully once that issue is resolved, the CTS will be updated.
18:08 karolherbst: pmoreau: but besides that everything is fine?
18:52 karolherbst: imirkin: 0x05400000 [0] GP104_3D.RT[0x5].ADDRESS_LOW = 0x5400000
18:52 karolherbst: but I assume this will probably get overwritten later on
18:52 karolherbst: ..
18:52 karolherbst: but I see a lot of references to this address
18:53 karolherbst: mhh.. maybe that bug isn't that hard to figure out actually
19:27 pmoreau: karolherbst: For the simple CTS link tests, yes (except that one of them does not compute the expected value).
19:27 pmoreau: I need to have a look at the generated binary.
19:30 karolherbst: mhhh
19:30 pmoreau: Loooool, the binary generated is just "exit": no wonder is does not compute the proper value! (It is supposed to do something like "*ptr = -*ptr".)
19:30 karolherbst: :D
19:30 karolherbst: lol
19:36 pmoreau: I am no NIR expert, but the generated NIR looks wrong (compared to the given input SPIR-V): https://pastebin.com/7PQC9p4M
19:36 karolherbst: quite
19:37 karolherbst: let's see
19:37 karolherbst: pmoreau: mind showing the output with NIR_PRINT=1
19:37 karolherbst: ?
19:37 pmoreau: Sure
19:38 pmoreau: Here you go: https://pastebin.com/ChrnHwq3
19:40 pmoreau: (This is using your clover_support_hmm_wip branch, with my IL program patches + NV50 patch, none of which should be touching the SPIR-V -> NIR parts.)
19:40 karolherbst: okay.. so I guess something with the function calling is broken
19:41 karolherbst: I thought I fixed that on that branch
19:41 karolherbst: ...
19:41 karolherbst: let me see
19:41 pmoreau: :-/
19:42 karolherbst: pmoreau: I pushed the branch, might checking if it's better?
19:43 karolherbst: ohh wait
19:43 karolherbst: no
19:43 karolherbst: pmoreau: let me do a proper rebase
19:45 pmoreau: Ok
19:51 karolherbst: pmoreau: branch updated
19:51 KungFuJesus: imirkin: I may finally have a little bit of free time to start investigating this again: https://gitlab.freedesktop.org/mesa/mesa/issues/1167
19:52 karolherbst: pmoreau: I am sure it works now, I just forgot to update to the new structurizer
19:52 KungFuJesus: I'm getting my gentoo G5 system up to date now. I'm hoping the issue that prevented yaboot from booting newer kernels has been fixed
19:52 imirkin: let's hope! i didn't have problems with yaboot and like 4.10 or so
20:00 linkmauve: So I finally have a 1070, but no power supply or RAM yet.
20:00 imirkin: linkmauve: keeping the habit alive?
20:01 linkmauve: Yay for dead weight!
20:01 linkmauve: Once I can power the thing, I’ll test it vs. the UHD630. :)
20:08 imirkin: should be competitive :)
20:08 KungFuJesus: yeah I don't either, I'm on 4.14, it's stuff newer than that that had issues
20:08 imirkin: KungFuJesus: ah ok. i don't think i went that high.
20:16 pmoreau: karolherbst: Thanks! Will try in a bit
20:33 karolherbst: ahhh
20:33 karolherbst: I can't map the uniform_bo :/
21:05 pmoreau: karolherbst: Kudos to you: test is now passing!
21:08 karolherbst: pmoreau: actually, I didn't fix it :d
21:08 karolherbst: pmoreau: https://gitlab.freedesktop.org/bbrezillon/mesa/-/commit/5e940006504ec95ad35e6eb4272cb04e4d47e9ed
21:08 karolherbst: was the fix
21:08 karolherbst: I just merged it into the other commits :p
21:09 pmoreau: Oh, I see! :-D
21:09 pmoreau: Not emitting the return value could be a problem indeed. :-D
21:09 pmoreau: I will update all the binaries to use the Input storage class for all BuiltIn variables, and see what I get. But at least basic linking tests work, so the infrastructure should be fine.
21:10 karolherbst: pmoreau: there will be more frequent updates though as now the collabora devs are working on that stuff as well for CL
21:10 karolherbst: still need to rebase on master, but jason did some bigger changes and I need to figure out what to do
21:10 pmoreau: No problems
21:11 karolherbst: others are also working on proper support for images :)
21:11 pmoreau: For the IL program series, I am mostly interested in testing the infrastructure than running all the possible SPIR-V programs. :-)
21:11 karolherbst: right
21:11 pmoreau: I saw you had some image support on your branch, that is great!
21:11 karolherbst: and I think that's fine
21:11 karolherbst: well.. yeah, but we will most likely go for a different approach
21:12 pmoreau: Though, probably not going to be too useful for me on NV50 since there’s probably some RE left to do.
21:12 karolherbst: I didn't do much of testing and I also have no motivation of working on that stuff thourughly
21:12 karolherbst: pmoreau: really?
21:12 karolherbst: at least we can the input buffer stuff worked on etc...
21:12 pmoreau: Right
21:12 karolherbst: wouldn't enable it by default though
21:12 karolherbst: as it's even worse tested than nvc0
21:12 karolherbst: compute support that is
21:13 karolherbst: pmoreau: for nv50 we do 32 bit addressing, right?
21:13 pmoreau: Well, I don’t think it is tested at all. :-D
21:13 pmoreau: Correct
21:13 imirkin: nv50 only supports 32-bit addressing
21:13 karolherbst: well
21:13 imirkin: fermi can support a hybrid of the nv50 way and the 64-bit way
21:13 karolherbst: technically we have 36 bits, no?
21:13 imirkin: yes
21:13 imirkin: you have 16 32-bit spaces
21:13 karolherbst: imirkin: I saw nvidia doing 32 bit addressing on pascal even
21:13 imirkin: which can be arranged however you like
21:14 imirkin: for global memory? i thought those insturctions faulted.
21:14 imirkin: maybe they brought it back
21:14 karolherbst: dunno, but you can compile 32 bit ptx just fine
21:14 imirkin: the methods which indicate what it's relative to are gone tho...
21:14 karolherbst: didn't really check at runtime though
21:14 pmoreau: What architectures are you testing on, btw? Should I expect things to work on Pascal (or even Turing)?
21:14 karolherbst: maybe they just 0 out the high bits...
21:14 karolherbst: never checked that deeply
21:14 karolherbst: pmoreau: pascal, yes
21:15 pmoreau: Okay, cool. I might try it on my desktop computer some day then, if I reboot on Linux.
21:18 DMJC: I'm trying to use nouveau on a a 770GTX.
21:18 DMJC: But I want to disable nouveau on a co-located 6800GT
21:18 DMJC: any idea if this is possible?
21:18 imirkin: define 'disable'
21:19 DMJC: I'm trying to run the 6800GT in a virtual machine as a PCI pass-through device. I don't want Linux touching it at all.
21:19 DMJC: The 770GTX is the host machine's GPU that I want Linux to grab/use.
21:19 imirkin: iirc the solution for that is to ensure that vfio-pci gets bound to it on boot
21:19 imirkin: i forget how you do that, iirc some cmdline thing
21:20 karolherbst: imirkin: libvirt handles that already
21:20 karolherbst: no manual interaction required
21:20 DMJC: yeah I can find that information, atm I seem to be getting crashes if I have modeset enabled (big white square and dead computer)
21:20 imirkin: libvirt is too late
21:20 karolherbst: just assigning the device to the VM
21:20 karolherbst: well
21:20 karolherbst: imirkin: nope
21:20 imirkin: nouveau needs to not bind
21:20 karolherbst: right
21:20 karolherbst: but you can unbind the device
21:20 imirkin: but by then it has been nouveau'd :)
21:20 karolherbst: but after that you don't need to do anything
21:21 karolherbst: doesn't matter
21:21 imirkin: it can.
21:21 karolherbst: yeah.. maybe
21:21 DMJC: nouveau is taking the entire system down so I need to stop it first.
21:21 imirkin: anyways, yeah, you can also unbind, but that's not always straightforward.
21:21 karolherbst: but then you can just blacklist nouveau :p
21:21 imirkin: he has another gpu which he wants to use with nouveau
21:21 imirkin: like i said ... cmdline args
21:21 karolherbst: ohh, I see
21:21 DMJC: yeah I'm basically asking for which nouveau cmdline arg disables the GPU I don't want touched.
21:22 imirkin: DMJC: vfio-pci.ids=10de:13c2
21:22 imirkin: or whatever
21:22 imirkin: that way nouveau never binds
21:22 imirkin: (assuming you don't get sad with load order)
21:23 imirkin: (i.e. make sure vfio-pci loads before nouveau does ... e.g. build it in, or play initrd tricks)
21:25 RSpliet: Heh, vfio-pci uses module_init. I always forget the order of those, but wouldn't it be sensible to have thar driver between bus and module?
22:09 karolherbst: ahhh.. this bug is annoying
22:09 karolherbst: and seriously the only one I hit in the CTS now
22:09 karolherbst: no other random fails