00:02Lyude: mupuf ^ btw, since you might be interested
00:03Lyude: if they're changing the value on the fly like that, I suspect there's some sort of gating bug they're working around with logic in the PMU :S
00:03Lyude: we probably could handle it from the CPU, but I have a feeling it'll be a lot more difficult to figure out when it's appropriate to change those bits
00:04Lyude: unless, hopefully, the logic it's using is obvious
00:07skeggsb: are you sure they still exist?
00:08Lyude: I would be surprised if they don't; they're showing the register values I'd expect along with the defaults I'd expect, and they're only being changed when the blob is loaded
00:09skeggsb: they're not protected by priv security, i can still apparently write them from the host at least
00:09Lyude: and when they are being changed, the values are still what I would expect. so far the only piece I've noticed the (probably) PMU changing so far is 0x020200 where it toggles ENG_CLK from AUTO->RUN occasionally
00:09Lyude: There wasn't anything I had running on this card at the time I noticed that (and I haven't noticed it once since, strangely enough), but I remember it seemed like nvidia did that in the past when changing the clock speed
00:10Lyude: that was just with the CPU though
00:11Lyude: at the very least, the only logic this really introduces is that we just need to know when to disable certain parts of clockgating before doing certain things
00:15Lyude: there we go, turning on a display makes it change more often
00:18Lyude: mupuf: how did you go about faking load on the card? going to need to mess around with reclocking on this card for a bit
00:30Lyude: so; after playing with glmark2 a little bit, I think what's happening is just that when the GPU clock is set to lower frequencies, it's likely that certain parts of the engine clockgating don't work correctly and need to be kept forced on until going into a higher power state
07:08mupuf: Lyude: I don't think you will ever need to disable clock gating. I assume it just does not save enough power and the lost latency makes it not worth it
07:30PaulePanter: The unresponsive X session at our user with Nouveau 1.0.15, X.Org X Server 1.19.6 and Linux 4.14.30 seems to be related to running XScreensaver.
07:31PaulePanter: `geodesic -root` is run on two monitors, but mouse and keyboard do not respond, and the screen is frozen.
07:34mupuf: Lyude: as for the tool to fake counters.... it is quite likely on the blob's partition of reator
07:39mupuf: Lyude: http://fs.mupuf.org/nvidia/ppwr_counters_fake.c
08:43PaulePanter: I created https://bugs.freedesktop.org/show_bug.cgi?id=106120. Please ask, if you have any questions.
11:58karolherbst: imirkin: we might have to start opting splits/merges away. https://gist.githubusercontent.com/karolherbst/3c59ba46a5d039d929a1a74104f8f3c4/raw/e7f53c777c5e0037c50435a4312f12d7bf1c5f8c/gistfile1.txt
11:59karolherbst: allthough I am not quite sure if I should split up 64 bit constants into 2 32 bit movs in the first place
11:59karolherbst: would make such issues less worse
11:59imirkin: 97: mov u64 %r252d 0x0000000000000004 (0)
12:00imirkin: where did that come from?
12:04karolherbst: some SSA opt
12:04karolherbst: it was splited pre SSA
12:04karolherbst: maybe something opts merges of two constants into a 64 bit mov
12:06karolherbst: yeah, with optimize=0 it doesn't happen
12:08karolherbst: imirkin: constantFolding is doing that
12:08karolherbst: line 678
12:17RSpliet: mupuf: there are hardware bugs related to clock/power gating that can be circumvented by temporarily disabling it I believe. From the top of my head something with NV9x context switching firmware getting corrupted on a perflvl change due to a hw bug in clock/powergating. Doesn't trace contain frequent re-uploading of ctxswitching firmware?
12:19karolherbst: RSpliet: migh explain why on Fermi they disable/enable it quite often
12:19karolherbst: and I suspect on Tesla as well
12:19karolherbst: kepler is the first gen where it becaome sane
12:20imirkin: karolherbst: ah fun. it shouldn't do that for mov's
12:20karolherbst: might prevent some other opts
12:20imirkin: or ... hm. dunno.
12:20karolherbst: where you opt 64 bit arithmetic
12:20karolherbst: and they don't care about merges
12:21karolherbst: imirkin: RA handles that good enough, so I think it is fine
12:21karolherbst: it is only problematic where we end up with a split again
12:23imirkin: why is it a 64-bit type in the first place?
12:23imirkin: oh, coz of the split
12:23imirkin: iirc i had a thing to const-prop splits
12:23imirkin: maybe not
12:23imirkin: or maybe it doesn't apply to 64-bit
12:24karolherbst: or maybe it happens to late
12:25karolherbst: Split64BitOpPreRA might split the 64 bit mad
12:25karolherbst: I sure it does
12:25karolherbst: 143: mul u64 %r253d %r252d %r249d
12:25karolherbst: 144: add s64 %r254d %r140d %r253d
12:25karolherbst: pre SSA
12:26karolherbst: so it gets opted into a 64 bit mad, and split into 32 bit ops in Split64BitOpPreRA
13:23karolherbst: imirkin: s takes a 32 bit address?
13:42imirkin_: i think it's 16MB max...
13:42imirkin_: or something like that
13:42imirkin_: actually probably max is a lot smaller than that
13:42imirkin_: either way, a single-width reg should be able to handle it just fine
13:42imirkin_: and there's no .E variant for LDS afaik
18:41Lyude: btw: any reason we don't just get the strap_peek automatically in nvagetbios?
19:46mupuf: Lyude: not a bad idea
19:46Lyude: mupuf: i'll add it in a little bit, once I finish up these register lists for maxwell2
19:47mupuf: 101000 is one of these numbers that so ingrained in my memory now
20:21Lyude: pcounter stuff goes into the pm engine in nouveau, right?
21:29mupuf: Lyude: yes
21:29mupuf: we never finished wiring that to the userspace
21:29mupuf: well, it is exposed now, but mesa does not make use of it
21:30Lyude: ah, cool, going to add some clkgate stuff to it then
22:40karolherbst: pmoreau: I see you find the first thing we want to run on our future nouveau vulkan implementation :p