04:46dboyan: imirkin, have you looked at my fp64-rcprsq2 branch?
04:47imirkin: not yet. see my email.
04:47imirkin: probably won't have time until next week.
04:48dboyan: okay, just saw that email.
05:19imirkin: alrighty... got a geforce 6200 pci on ebay. hopefully that'll help me play with some of the nv4x issues
11:37dboyan: 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:37dboyan: my demmt is still able to annotate old traces generated before
11:43pmoreau: 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:06dboyan: pmoreau: I don't think I've seen any error messages. Really strange...
12:09karolherbst: dboyan: did you check the log?
12:09karolherbst: I recently did a mmt trace for imirkin_ and it worked out
12:09dboyan: what log?
12:09karolherbst: and I usually have the newest drivers
12:09karolherbst: no idea if it was on 378 though
12:09karolherbst: dboyan: the trace log
12:10dboyan: karolherbst: I don't think I've found anything interesting.
12:11dboyan: Just all the hex numbers
12:11dboyan: and object trees
12:12dboyan: my driver is 378.13 and I was using 375.26 before
12:18dboyan: 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:18dboyan: I gtg now, will return in 2 hrs
13:50dboyan: imirkin_, I think there is some issue with your envytools commit 808452045
13:50dboyan: envydis now aborts when disassembling some instructions on gk110 like 029ffc1a dfc02800
13:52dboyan: The first entry of tabus64_28 doesn't have a name, that causes the abort when disassembling instructions of this kind
13:53dboyan: 029ffc1a dfc02800: SHF.L R6, RZ, R5, R10;
13:54dboyan: 029ffc1a dfc02a00: SHF.L.U64 R6, RZ, R5, R10;
13:54dboyan: 029ffc1a dfc02b00: SHF.L.S64 R6, RZ, R5, R10;
13:54dboyan: No idea what the first form means though
19:00john_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:22karolherbst: has anybody checked nouveau on the 4.10 tree yet?
20:23karolherbst: on reator the X server just locks up
20:35karolherbst: at 0f the fermi GPU just felt off the bus
20:36john_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:37karolherbst: john_cephalopoda: is your software up to date?
20:37karolherbst: also what gpu and version of mesa/xf86-video-nouveau/kernel
20:38john_cephalopoda: Kernel 4.10, Mesa 13.0.5, xf86-video-nouveau 1.0.13
20:39john_cephalopoda: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 645 OEM] (rev a1)
20:39john_cephalopoda: This thing has been happening for ages though.
20:40karolherbst: is there a reliable way to trigger it?
20:40john_cephalopoda: Starting Hyper Light Drifter
20:41karolherbst: could you make an apitrace?
20:41john_cephalopoda: In general, resizing windows in my WM (i3wm) and starting applications with fixed resolution in a big window.
20:42karolherbst: I see
20:42karolherbst: it could be some X mess up
20:42karolherbst: something wrong inside the nouveau ddx
20:42karolherbst: john_cephalopoda: mind uninstalling xf86-video-nouveau and restart X?
20:42john_cephalopoda: Wait, gotta run to the store. When I am back, I will continue.
21:06karolherbst: skeggsb: d4671e9534d5f5c67130c0fa429708e40fe415d4 broke X on reator
21:06karolherbst: when starting X it just locks up at some point
21:08karolherbst: modesetting should be picked up
21:08john_cephalopoda: Removing xf86-video-nouveau breaks my X
21:08karolherbst: john_cephalopoda: is there a package like xf86-video-modesetting?
21:08karolherbst: it would be odd, because it is embedded into the X server now
21:09karolherbst: is there something inside /etc/X11/xorg.conf ?
21:10karolherbst: yeah, you don't need this
21:10karolherbst: remove the xorg.conf file and X should start again
21:12john_cephalopoda: I started in an other tty. It starts this time.
21:12john_cephalopoda: The same issue happens again though.
21:12john_cephalopoda: And now the artifacts flicker.
21:12karolherbst: mhhh okay
21:12karolherbst: so it is unrelated to the X driver
21:45mslusarz: 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:46mslusarz: if you want to fix this, figure out how to correctly inject GET_CHIPSE method with this blob version and redo the trace
21:49karolherbst: mupuf: you know of any issues tracing the nvce?
23:09RSpliet: just throwing this out here for future Roy: timing_10_20 == tFAW
23:11karolherbst: RSpliet: are you aware of any engine reclocking issues on fermi?
23:12RSpliet: karolherbst: no, but also didn't spend a lot of time on it
23:12karolherbst: because when I reclock a fermi card with the current code, the gpu falls of the bus
23:12RSpliet: I think I've seen something like that happen...
23:12karolherbst: might be something worth to know for you
23:13RSpliet: Not ideal
23:13karolherbst: not that you think that you screwed up with memory reclocking
23:13karolherbst: and then it's just the engine
23:13RSpliet: Oh I probably did...
23:13karolherbst: well the lower pstates seems to work fine though
23:14RSpliet: 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:14karolherbst: sadly I can't get nvidia traced on fermi...
23:14karolherbst: gpu... messes up
23:16karolherbst: "NVRM: GPU at 0000:05:00.0 has fallen off the bus." ....
23:17karolherbst: hu, I think it's enough
23:17karolherbst: there is a full reclock in the trace
23:17RSpliet: there should be some traces in the repo for me
23:17karolherbst: yeah, but I want to work on this on mupufs nvce
23:19karolherbst: it's odd though, cause I thought we need the same code on fermi and kepler
23:20karolherbst: but the clocks on fermi are also like total garbage, so maybe that's it
23:20karolherbst: and we just configure the PLLs in a very unstable way
23:20karolherbst: P=0x1 in every case
23:22karolherbst: ohh, kepler indeed has it's own code partly
23:24RSpliet: More notes to future Roy: double check whether timing_10_13 == tXPDLL, timing_10_18 == tXP, timing_10_21 == tCKE ?
23:24mupuf: karolherbst: want me to plug another gpu?
23:25karolherbst: another fermi, yes
23:25RSpliet: 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:26RSpliet: no, that sounds wrong... but still, RTP seems quite useful to have :-P
23:29karolherbst: mupuf: but at least on your nvce, pixmark_piano went from 16 to 124 points :D
23:29karolherbst: 0x3 vs 0x7 pstate
23:29mupuf: karolherbst: fuck, that is extreme!
23:29karolherbst: on 0x3 you have 50MHz
23:29karolherbst: on 0x7 405MHz already
23:37mupuf: shit, this is like the nvc0
23:37karolherbst: well some fermis boot on 0x7 already
23:37karolherbst: but yeah, I was surprised as well