00:38 JayFoxRox: RSpliet: see my note in the first post. if the maintainers are fine with adding setuptools, then rnndb can be installed through tools like pip, without being an official distribution
00:38 JayFoxRox: it's basically just another way of `git clone` to the proper directories so the files can be found systemwide
00:38 JayFoxRox: that's probably easier for most people than going through the trouble of doing it manually + my own scripts can auto-install it then
00:39 JayFoxRox: (using setuptools / standard python methods)
00:40 JayFoxRox: rhyskidd: I don't want to run these as scripts, but use their existing code in my project (ideally with as little installation overhead as possible, and avoiding manually updates like submodules)
00:40 rhyskidd: how tightly are valgrind-mmt and demmt tied to each other, in terms of properly recording and decoding new ioctls?
00:41 rhyskidd: e.g. i'm seeing some odd behaviour, and wondering whether valgrind-mmt missed some data for an ioctl on a dev char
00:41 JayFoxRox: [my comments are re distribution / setuptools for rnn and rnndb]
00:49 karolherbst: rhyskidd: depends
00:49 karolherbst: rhyskidd: demmt has to know how much data an ioctl has
00:49 karolherbst: and demmt should be able to decode it
00:49 karolherbst: rhyskidd: also, keep in mind, that without my patches, tracing compute stuff is super unreliable
00:49 imirkin: Lyude: all good, thanks
01:50 ToxicSauce: ok this is super weird. running void linux with nouveau drivers. When I first boot and am in tty1, I get 2 out of my three monitors working properly at the proper resolution, with the third monitor with no video output. when launched into x, all three monitors are detected in xrandr and I can move my mouse through the middle monitor like it has a graphics output to it. When in tty1 if I power cycle
01:50 ToxicSauce: the monitor that is not displaying anything, the monitors all flicker and then stop displaying anything at all and the system freezes.
01:51 ToxicSauce: running all of this through gpu passthrough in a kvm vm with a GTX1060
01:51 ToxicSauce: I have a windows vm with the exact same settings that works perfectly with all three monitors
01:52 imirkin: ToxicSauce: pastebin dmesg + xorg log
01:55 ToxicSauce: dmesg: http://ix.io/1m4d
01:55 imirkin: rhyskidd: almost not at all tied together
01:55 imirkin: rhyskidd: the one thing is that valgrind-mmt will issue an extra ioctl to detect the card version, which has to work with that blob version
01:56 ToxicSauce: I need to reinstall X again, hold on a sec for logs
01:56 imirkin: ehhh
01:56 imirkin: not necessary
01:56 ToxicSauce: trying a fresh install after the nvidia drivers broke things
01:56 imirkin: [ 3.835129] nouveau 0000:00:02.0: disp: outp 03:0006:0f44: link rate unsupported by sink
01:56 imirkin: either we, or the sink (aka monitor), or some combination, are doing something wrong
01:57 ToxicSauce: ah
01:57 imirkin: however it seems much more likely that we'll be able to adjust what we do, vs the monitor firmware...
01:57 ToxicSauce: 2 monitors are the same model and one is different. all running on displayport
01:57 imirkin: can you boot with nouveau.debug=disp drm.debug=0x1e
01:58 ToxicSauce: in kernel params?
01:58 ToxicSauce: sure
01:58 imirkin: yes
01:58 imirkin: that should give us a better idea of wtf is failing
01:58 imirkin: is there MST involved btw? (i.e. daisy-chaining)
01:59 ToxicSauce: no, three normal displayport cables each on a separate output of the 1060
01:59 imirkin: k =/
01:59 imirkin:likes to blame what he doesn't understand
01:59 ToxicSauce: lul
02:00 ToxicSauce: ok, dmesg again?
02:00 imirkin: aye
02:00 ToxicSauce: http://ix.io/1m4e
02:02 imirkin: gr
02:02 imirkin: this doesn't have what i wanted
02:02 imirkin: hold on.
02:02 ToxicSauce: I believe the output is DP-2 fyi
02:02 ToxicSauce: taht is having trouble
02:05 imirkin: something must have changed about how that debug parameter works... sec
02:08 imirkin: no, should still work.... hrmph
02:08 imirkin: oh, but perhaps CONFIG_NOUVEAU_DEBUG_DEFAULT is higher than i think
02:08 imirkin: let's try again with
02:09 imirkin: nouveau.debug=disp=trace drm.debug=0x1e
02:15 ToxicSauce: =disp=trace ?
02:15 ToxicSauce: just confirming?
02:16 imirkin: yes
02:16 ToxicSauce: http://ix.io/1m4h
02:19 imirkin: yeah ok
02:19 imirkin: so training just totally fails on that second output
02:19 imirkin: it's questionable why it even tries 1x540MB/s
02:19 imirkin: but it does that only after it tries 4x270, 4x162, and 2x270
02:20 imirkin: (2x162 would not be enough since it wants 357M)
02:21 imirkin: sorry, this is above my paygrade
02:21 imirkin: skeggsb: --^
02:21 ToxicSauce: np, thanks for the help
02:22 imirkin: ToxicSauce: try HDMI :)
02:22 ToxicSauce: would dvi work? I only have dvi cables that are long enough
02:23 imirkin: sure
02:23 ToxicSauce: kk
02:23 imirkin: it's 1680x1050 or whatever
02:23 imirkin: even single-link DVI can do 1920x1200@60 no problem
02:23 imirkin: and 2560x1440 with DVI-DL
02:25 imirkin: also, irony of ironies, i suspect that daisy-chaining that monitor would actually work out ok
02:25 imirkin: if any of the other two have DP outs
02:34 rhyskidd: do we have a better sense of what actual ACR/scrubber bugs were fixed by applying the GP108 firmware back to the other GP10x?
02:35 rhyskidd: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=85c5d90fc155d78531efa5d2b02e92aaef7e4b88
02:35 skeggsb: rhyskidd: unfortunately no, if that changes, i will let you know
02:36 skeggsb: the symptoms, however:
02:36 rhyskidd: ok, well i'll give it a try with my GP107M, maybe it will fix one of the issues I've been having!
02:36 skeggsb: "VPR scrubber failed" on some chips
02:36 rhyskidd: hrmm, ok
02:36 imirkin: and we all know what that means
02:36 skeggsb: and "HS load failed, ret 0x00000023" on others
02:37 imirkin: i guess good to keep a record, go through bugzilla and tell people to test it out
02:37 ToxicSauce: imirkin: they are pretty inexpensive monitors so no daisy chaining. they have display port, dvi, vga
02:37 ToxicSauce: and old
02:37 rhyskidd: yup, thanks
02:41 ToxicSauce: imirkin: dmesg with dvi, http://ix.io/1m4m
02:41 ToxicSauce: still having the same monitor not display anything.
02:56 imirkin: gyah
02:58 imirkin: is that monitor now plugged in via dvi?
02:58 ToxicSauce: yep and only dvi
02:59 imirkin: you sure you don't need to press some buttons on it?
02:59 imirkin: (to flip the input)
03:00 ToxicSauce: yep, already checked that
03:00 ToxicSauce: I don't use autodetect on the monitors
03:02 ToxicSauce: so that is interesting. I tried power cycling the monitor while I have it connected via DVI and I didn't get the same issue of the computer freezing. It just went back to having no output and the other two monitors were unaffected.
03:03 ToxicSauce: I know that when I unplugged the monitor when it was connected via dvi, I got some nouveau errors about i2c things
03:12 imirkin: skeggsb:
03:12 imirkin: [ 3.794748] nouveau 0000:00:02.0: disp: head-0: on SOR-2
03:12 imirkin: and just a little later
03:12 imirkin: [ 3.825873] nouveau 0000:00:02.0: disp: head-0: to SOR-1
03:12 imirkin: does that seem odd to you?
03:13 imirkin: skeggsb: this is in http://ix.io/1m4m where there's 2 DP and 1 DVI-D plugged in
03:19 ToxicSauce: imirkin: I need to head to bed fairly shortly but I am on a bouncer so will get replies. Else I cna check logs
03:19 imirkin: cool
03:21 ToxicSauce: thanks for the help
12:54 pendingchaos: imirkin, karolherbst: if you do "sched (st 0x1 wr 0x0) (st 0x1 wr 0x0)", does the second instruction wait for the first to write it's result?
12:59 imirkin: don't think so
13:00 imirkin: you need a wt 0x1 or rd 0x1 in there iirc
13:00 imirkin: er no. just wt 0x1.
13:00 imirkin: rd 0x1 is signaled when an instruction is done reading its args
13:01 imirkin: as for testing the ddx, you can use rendercheck
13:01 imirkin: and some targeted tests like try playing a video using xvideo
13:01 pendingchaos:nods
13:01 pendingchaos: I think it's possible for SchedDataCalculatorGM107 to create code like that
13:01 pendingchaos: I might try and get it to do so sometime
13:36 karolherbst: imirkin: quick idea on how to trigger an engine reset with a shader_test file? Otherwise I just hack shader_runner itself do start doing stupid things
15:25 pendingchaos: imirkin: is it usual for rendercheck's tests to take a while?
15:28 pendingchaos: specifically "blend test on ..." and "composite mask test on ..."
16:34 mupuf: pendingchaos: rendercheck is quite slow, yes
16:38 pendingchaos: mupuf: is there any way to speed it up while still testing things well enough?
16:40 mupuf: run it in parallel?
16:40 mupuf: you can specify different formats in different instances
16:43 pendingchaos: I suspect much of the work is in the x server though
16:43 mupuf: there is a lot of serialisation going on, neither the gpu nor cpu are that busy
17:35 pendingchaos: mupuf: is it usual for "Beginning composite mask test on a8" to take hours?