04:46 dboyan: imirkin, have you looked at my fp64-rcprsq2 branch?
04:47 imirkin: not yet. see my email.
04:47 imirkin: probably won't have time until next week.
04:48 dboyan: okay, just saw that email.
05:19 imirkin: alrighty... got a geforce 6200 pci on ebay. hopefully that'll help me play with some of the nv4x issues
11:37 dboyan: I upgraded the blob driver to 378.13 today, and it seems demmt won't annotate traces generated under this new driver. Any idea about what has happened?
11:37 dboyan: my demmt is still able to annotate old traces generated before
11:43 pmoreau: dboyan: Is there an error message? But otherwise, having issues with demmt on new blob versions is not unheard of, especially if it involves compute.
12:06 dboyan: pmoreau: I don't think I've seen any error messages. Really strange...
12:07 pmoreau: :-/
12:09 karolherbst: dboyan: did you check the log?
12:09 karolherbst: I recently did a mmt trace for imirkin_ and it worked out
12:09 dboyan: what log?
12:09 karolherbst: and I usually have the newest drivers
12:09 karolherbst: no idea if it was on 378 though
12:09 karolherbst: dboyan: the trace log
12:10 dboyan: karolherbst: I don't think I've found anything interesting.
12:11 dboyan: Just all the hex numbers
12:11 dboyan: and object trees
12:12 dboyan: my driver is 378.13 and I was using 375.26 before
12:18 dboyan: For anyone who's interested, I put 2 mmt traces of the same program in https://people.freedesktop.org/~dboyan/mmt/, the old one works but the new one doesn't work
12:18 dboyan: I gtg now, will return in 2 hrs
13:50 dboyan: imirkin_, I think there is some issue with your envytools commit 808452045
13:50 dboyan: envydis now aborts when disassembling some instructions on gk110 like 029ffc1a dfc02800
13:52 dboyan: The first entry of tabus64_28 doesn't have a name, that causes the abort when disassembling instructions of this kind
13:53 dboyan: 029ffc1a dfc02800: SHF.L R6, RZ, R5, R10;
13:54 dboyan: 029ffc1a dfc02a00: SHF.L.U64 R6, RZ, R5, R10;
13:54 dboyan: 029ffc1a dfc02b00: SHF.L.S64 R6, RZ, R5, R10;
13:54 dboyan: No idea what the first form means though
18:58 john_cephalopoda: Hey.
19:00 john_cephalopoda: When I resize a window faster than it can update, or start a windowed application in fullscreen, I sometimes get some graphics memory content shown for a split second. The things that are displayed sometimes stem from long-closed application and even survive a reboot.
20:22 karolherbst: mhhh
20:22 karolherbst: has anybody checked nouveau on the 4.10 tree yet?
20:23 karolherbst: on reator the X server just locks up
20:35 karolherbst: okay
20:35 karolherbst: at 0f the fermi GPU just felt off the bus
20:36 john_cephalopoda: Oh, btw, this is a screenshot of the weird artifacts I get. I rebooted freshly, the media player and IRC weren't open in that session yet: https://lut.im/kMgX8FSPjI/Xi6Hu5pE8sYPu3Cm.png
20:37 karolherbst: john_cephalopoda: is your software up to date?
20:37 karolherbst: also what gpu and version of mesa/xf86-video-nouveau/kernel
20:38 john_cephalopoda: Kernel 4.10, Mesa 13.0.5, xf86-video-nouveau 1.0.13
20:39 john_cephalopoda: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 645 OEM] (rev a1)
20:39 john_cephalopoda: This thing has been happening for ages though.
20:39 karolherbst: interesting
20:40 karolherbst: is there a reliable way to trigger it?
20:40 john_cephalopoda: Starting Hyper Light Drifter
20:40 john_cephalopoda: :þ
20:41 karolherbst: mhhh
20:41 karolherbst: could you make an apitrace?
20:41 john_cephalopoda: In general, resizing windows in my WM (i3wm) and starting applications with fixed resolution in a big window.
20:42 karolherbst: I see
20:42 karolherbst: it could be some X mess up
20:42 karolherbst: something wrong inside the nouveau ddx
20:42 karolherbst: john_cephalopoda: mind uninstalling xf86-video-nouveau and restart X?
20:42 john_cephalopoda: Wait, gotta run to the store. When I am back, I will continue.
21:04 john_cephalopoda: Back
21:05 john_cephalopoda: brb
21:06 karolherbst: skeggsb: d4671e9534d5f5c67130c0fa429708e40fe415d4 broke X on reator
21:06 karolherbst: when starting X it just locks up at some point
21:08 john_cephalopoda: https://bpaste.net/raw/e799e828f3e0
21:08 karolherbst: huh
21:08 karolherbst: modesetting should be picked up
21:08 john_cephalopoda: Removing xf86-video-nouveau breaks my X
21:08 karolherbst: john_cephalopoda: is there a package like xf86-video-modesetting?
21:08 karolherbst: it would be odd, because it is embedded into the X server now
21:09 karolherbst: well
21:09 karolherbst: is there something inside /etc/X11/xorg.conf ?
21:09 john_cephalopoda: https://bpaste.net/show/b94c5b9c8549
21:10 karolherbst: yeah, you don't need this
21:10 karolherbst: remove the xorg.conf file and X should start again
21:12 john_cephalopoda: I started in an other tty. It starts this time.
21:12 john_cephalopoda: The same issue happens again though.
21:12 john_cephalopoda: And now the artifacts flicker.
21:12 karolherbst: mhhh okay
21:12 karolherbst: so it is unrelated to the X driver
21:45 mslusarz: dboyan: I had a quick look at those traces: the bad one fails because demmt doesn't know what is the chipset id the trace was obtained on and it doesn't know because GET_CHIPSET method call (injected by valgrind-mmt) failed
21:46 mslusarz: if you want to fix this, figure out how to correctly inject GET_CHIPSE method with this blob version and redo the trace
21:49 karolherbst: mupuf: you know of any issues tracing the nvce?
23:09 RSpliet: just throwing this out here for future Roy: timing_10_20 == tFAW
23:11 karolherbst: RSpliet: are you aware of any engine reclocking issues on fermi?
23:12 RSpliet: karolherbst: no, but also didn't spend a lot of time on it
23:12 karolherbst: k
23:12 karolherbst: because when I reclock a fermi card with the current code, the gpu falls of the bus
23:12 RSpliet: I think I've seen something like that happen...
23:12 karolherbst: might be something worth to know for you
23:12 karolherbst: :D
23:13 RSpliet: Not ideal
23:13 karolherbst: not that you think that you screwed up with memory reclocking
23:13 karolherbst: and then it's just the engine
23:13 karolherbst: (s)
23:13 RSpliet: Oh I probably did...
23:13 karolherbst: well the lower pstates seems to work fine though
23:14 RSpliet: but equally I was able to change the cards speeds when disabling mem reclocking, so might just be a problem with highest pstate (and two-step config)
23:14 karolherbst: yeah
23:14 karolherbst: sadly I can't get nvidia traced on fermi...
23:14 karolherbst: gpu... messes up
23:16 karolherbst: "NVRM: GPU at 0000:05:00.0 has fallen off the bus." ....
23:17 karolherbst: hu, I think it's enough
23:17 karolherbst: there is a full reclock in the trace
23:17 RSpliet: there should be some traces in the repo for me
23:17 karolherbst: yeah, but I want to work on this on mupufs nvce
23:19 karolherbst: it's odd though, cause I thought we need the same code on fermi and kepler
23:20 karolherbst: but the clocks on fermi are also like total garbage, so maybe that's it
23:20 karolherbst: and we just configure the PLLs in a very unstable way
23:20 karolherbst: P=0x1 in every case
23:22 karolherbst: ohh, kepler indeed has it's own code partly
23:22 karolherbst: fun
23:24 RSpliet: More notes to future Roy: double check whether timing_10_13 == tXPDLL, timing_10_18 == tXP, timing_10_21 == tCKE ?
23:24 mupuf: karolherbst: want me to plug another gpu?
23:24 mupuf: cf?
23:25 karolherbst: another fermi, yes
23:25 RSpliet: And a final note to Roy: how the hell do they derive tRTP? Is that tRC - tCAS (and something with AL which is always 0)?
23:26 RSpliet: no, that sounds wrong... but still, RTP seems quite useful to have :-P
23:29 karolherbst: mupuf: but at least on your nvce, pixmark_piano went from 16 to 124 points :D
23:29 karolherbst: 0x3 vs 0x7 pstate
23:29 mupuf: karolherbst: fuck, that is extreme!
23:29 karolherbst: well
23:29 karolherbst: on 0x3 you have 50MHz
23:29 karolherbst: on 0x7 405MHz already
23:37 mupuf: shit, this is like the nvc0
23:37 karolherbst: well some fermis boot on 0x7 already
23:37 karolherbst: but yeah, I was surprised as well