08:38mupuf: karolherbst: enjoy: https://pastebin.com/raw/drE8NVfL
08:38mupuf: it is booted and ready for your fun
08:39mupuf: I updated the machine too
08:39mupuf: need to check why wtrpm is down
11:32karolherbst: mupuf: heh... something is weird with all machines except mine... I am not able to read through the /dev/i2c-* devices... provided by the nvidia driver :/
11:36karolherbst: at least nvaspyi2c works on the titan
11:41RSpliet: karolherbst: if permission problems appear random, suspect selinux/apparmor/... :-P
11:41karolherbst: RSpliet: https://gist.github.com/karolherbst/cec4741e11a3b11a8fd434972b6eeb42
11:43karolherbst: on my gm204 that's different :/
11:43karolherbst: even same driver version
11:43karolherbst: using i2cget is so much less pain than nvaspyi2c, because I don't have to deal with false reads
11:43karolherbst: false reads: value <-> reg matching is off for some values
11:45RSpliet: Is that because nvaspyi2c doesn't properly enforce mutual exclusive access to the bus, on account of directly talking to the hardware rather than having the driver sit in the middle?
11:45karolherbst: RSpliet: nvaspyi2c uses mmio
11:45karolherbst: so it just spies on whatever values are inside mmio right now
11:47RSpliet: Mmm, anyway, I was being only semi-serious blaming selinux... it somehow always ends up deserving blame for permission errors
11:47RSpliet: I take it NVIDIA doesn't use third party i2c controllers (of varying types) to wiggle the wire, but just use the same internal block across all gens of HW?
11:48karolherbst: but I have the same issue on my laptop as well... maybe I did something in my own kernel config so that it works?
11:48karolherbst: no idea
11:49RSpliet: Possible... sadly, I'm not familiar enough with i2c in the kernel to say much meaningful about it
11:49karolherbst: there aren't any relevant options :/
11:49RSpliet: Happily play a rubber duck helpdesk for a bit though
11:50RSpliet: Btw, the "gist" paste you just shared, is that for a gm204 as well?
11:52mupuf: karolherbst: you are lucky that it works at all on your case, yeah
11:52karolherbst: mhhh, odd
11:52mupuf: the reason why /dev/i2c-* devices don't work is because pdaemon is in control of the i2c lines
11:52mupuf: you can change that, you would need to be careful
11:52karolherbst: okay, sure, but why does it work on my machine then
11:54karolherbst: ohh I might have an idea
11:57mupuf: karolherbst: heck if I know why pdaemon would not be responsible for this on your machine ;)
11:57karolherbst: now it's yes
11:58karolherbst: now verifying that what I did indeed changed it
11:58karolherbst: i2cget -y 9 0x40 0xff w: 0x2032 :)
11:59karolherbst: mupuf: "options nvidia-drm modeset=1" :D
11:59karolherbst: that changes it
11:59karolherbst: with that after loading nvidia-drm, the i2c devices are readable
11:59mupuf: ok, cool!
11:59karolherbst: yeah.. running with that option on my machine
11:59karolherbst: because plymouth shows on external displays with it :)
12:00karolherbst: and because of full disc encryption, I needed that
12:05karolherbst: mupuf: I don't think it's that...
12:06karolherbst: when I have nvidia-smi running in the background in interval mode, then it's readable
12:06karolherbst: otherwise not
12:06mupuf: well, that's what's happening then. Nvidia-smi is polling directly
12:08karolherbst: but.. on my machine there was no nvidia-smi running... I'll guess it can hapen for whatever reason
12:09karolherbst: like connected displays
12:09karolherbst: or something
12:09karolherbst: my display is connected via DP, so
12:09karolherbst: heh! on the titan the sensor is underreporting
12:11mupuf: that is good news!
12:14karolherbst: mhh, but by not much
12:14karolherbst: 1-2 W
12:14HdkR: Pretty small considering how much power it pulls at load
12:15karolherbst: yeah..., well glxgears
12:15karolherbst: so it was only 100W
12:19karolherbst: mupuf: on the 960 we are quite close. like a 0.4W difference
12:19karolherbst: _but_, there is a difference
12:22mupuf: karolherbst: please use i2cspy here
12:22mupuf: this is the only way to guarantee you don't get the wrong values
12:23karolherbst: right.. but some prints are just wrong from i2cspy :/
12:23karolherbst: some lines
12:23karolherbst: and I'd need to filter those out somehow
12:24karolherbst: mupuf: btw, can I safely reboot the machine?
12:25mupuf: yes, should be fine, but seems like someone did not read the memo and called grub-reboot on the blob distro... which prevents booting on nouveau
12:25mupuf: I will re-install everything
12:25mupuf: and have one distro for everything
12:25mupuf: and scripts to switch from nouveau to the blob
12:26mupuf: hail to libglvnd
12:26karolherbst: yeah.. that makes it easier
12:26karolherbst: on my machine I have some dracut config to switch, and gentoos eselect-opengl module... they still don't have glvnd, sadly
12:27karolherbst: ohh, now they have
12:27karolherbst: have to check it out
12:28mupuf: lol, living in the past, I see ;)
12:28karolherbst: well, there was a libglvnd ebuild for a year or more already
12:28karolherbst: just no bits in mesa to make use of it
12:29karolherbst: was added in 19.0-rc6, interesting
12:30mupuf: hmm, arch was a bit more experimental here: they backported it to mesa 17.0 in feb 2017
12:30mupuf: seems like fedora did it first though
13:56karolherbst: mupuf: uff, seems like I got reator to hang while rebooting :/
13:59mupuf: it takes time, for some reason
14:15karolherbst: mupuf: nope.. seems like I messed up for good :/
14:19mupuf: you'll havew to wait until I come back home then
14:20karolherbst: yeah, but I am out in the evening anyway, so maybe for tomorrow again then
14:21mupuf: we'll see
14:21mupuf: I'll try to fix wtrpm
14:21karolherbst: okay, cool :)
14:35HdkR: What is reator?
14:36RSpliet: HdkR: A machine in mupuf's livingroom
14:42mupuf: RSpliet: very accurate, indeed!
15:39karolherbst: mupuf: so, currently I have two ideas: 1. one power budget lines is an offset we have to apply on top of the sensor readings 2. something in the rail entries makes something witht the value. Any other ideas where to look?
16:04mupuf: no, I think you are on the right track
16:05mupuf: it is possible that only some lanes are monitored and not the others
16:05mupuf: but we should extrapolate the values
16:05mupuf: so this should be explained on a per-rail granularity
16:05karolherbst: mupuf: even with one lane it doesn't really fit I think
16:06karolherbst: mhhh, actually, only checking channl0 gets me quite close...
16:07karolherbst: -2.5W difference
16:07mupuf: what do you mean with: only with one lane, it does not fit?
16:07mupuf: lanes should be summed up for sure
16:07mupuf: they might need to be scaled
16:07karolherbst: apperantly... not
16:08karolherbst: keep in mind that this GPU only has one power supply
16:08karolherbst: not two (or three)
16:08mupuf: you get the 3.3 and the 12V rails
16:09mupuf: what's the voltages read?
16:09karolherbst: 1.55V both
16:09mupuf: well, that is odd :D
16:09karolherbst: both lanes have more or less the same bus voltage
16:09karolherbst: in every read
16:10mupuf: I see, so there are 2 VRs
16:10mupuf: there is one that drops the voltage to 1.55V, then another lowering it again
16:18karolherbst: mupuf: but I guess one channel could monitor only a part of the GPU and the other ones the entire GPU
16:20karolherbst: yeah... only channel0 gives me much better values overall
16:20karolherbst: running heaven right now
16:25karolherbst: my values are around 2-4W lower though
16:25karolherbst: but that's a constant offset now
16:26mupuf: well, your theory is indeed sensible
16:26mupuf:would expect tags on the rails for this purpose
16:26karolherbst: yeah.. there are some unknown bits set on the rail
16:26mupuf: given that they have such tags for the temperature sensors, we can expect the same
16:27mupuf: good theory, dude!
16:28karolherbst: well, it's a MXM card.. there is no point on having two channels afterall
16:29karolherbst: which... might make things interesting for cards with three enabled channels
16:29mupuf: memory might be tracked separately ;)
16:29mupuf: ALL + memory
16:29karolherbst: I would expect one for each power supply, but usually you have the same cable on both extra PINs
16:30karolherbst: mupuf: that would mean with piano the memory consumption should be nearly 0 :p
16:31karolherbst: mupuf: I think it's ALL + SMs
16:31karolherbst: with piano it's like 100% / 83%
16:32karolherbst: but yeah.. I guess I can play around with that by messing with the voltage as well
16:33karolherbst: will be fun
16:33karolherbst: anyway, gotta go
16:40mupuf: ALL + CORE
16:40mupuf: ALL = CORE + MEM + OTHERS
16:40mupuf: karolherbst: what voltage is the RAM supposed to be running at?
19:02m00n: Are there any nouveau devs online? Had a question about how I can help out to try to get SLI working, about experience required etc
22:38karolherbst: mupuf: unknown from out point of view
22:38karolherbst: m00n: do you have two GPUs with an SLI interconnect?
22:42HdkR: Sounds like you would need to figure out how to cause SLI copies mainly :P
22:49karolherbst: HdkR: the most problematic parts are the mesa changes actually :/
22:50karolherbst: sure you could just split at 50% of the frame or something...
22:51HdkR: Oh yea. That's a bit of a dorky problem
22:52HdkR: ALso need to implement all the NVAPI crap to handle SLI games I guess :P
22:53karolherbst: ;) that would be step two
22:55HdkR: I wonder if there were even any SLI or Crossfire games released on Linux
23:26gnarface: i thought the quake3 engine supported SLI but i could be wrong
23:26gnarface: i know it supports SMP but it was disabled by default because it was a net loss of performance at the time
23:27karolherbst: gnarface: well, doing multithreading in a performant way is difficult ;)
23:41gnarface: ioquake3 is in the debian repos, it's just missing maps