00:00 imirkin: thican: does modesetting work ok?
00:25 trippeh_: something came up, no mmiotracing today.
08:33 thican: imirkin: no idea :/
08:34 thican: I don't know what this is.
10:16 karolherbst: thican: he meant if you get something displayed, which is not a crappy resolution
10:16 karolherbst: aka native resolution and you can change them and stuff like that
10:33 karolherbst: mupuf_: fyi example code using nvctrl: https://gist.githubusercontent.com/karolherbst/4341e3c33b85640eaaa56ff69a094713/raw/c976daa9e406d37e01351357ea9d8c20d5097d66/nvctrl.c
10:33 thican: karolherbst: well, the TTY was in nice resolution
10:33 thican: but I wasn't able to start X
10:34 karolherbst: thican: anything in the X log?
10:35 thican: oh, I forgot it x(
10:36 karolherbst: you won't be able to use the nouveau ddx I think, so it has to be the modesetting one
10:36 karolherbst: or maybe you can use the nouveau one
10:36 karolherbst: but better check the logs
10:38 thican: karolherbst: I don't know if you got the dmesg dump http://www.zdnet.fr/actualites/d-inquietantes-failles-de-securite-dans-les-acces-fibre-optique-ftth-en-france-39844258.htm
10:38 thican: oops…
10:38 thican: https://paste.pound-python.org/show/v9E8IC1wPTf0EpNsPGIQ
10:41 karolherbst: yeah I saw it
13:12 karolherbst: fun, those powermizer offsets are multiple of 2 internally
13:12 karolherbst: 2 -> 2, 3 -> 2, 4 -> 4
13:22 karolherbst: \o/ I can change the offsets from cli now, this should make it much easier to RE the pmu mem counter to memory load mapping :)
13:58 karolherbst: mupuf_: your ppwr_counters_fake tool isn't precise enough :(
13:58 mupuf_: yeah, I know, it's annoying
13:58 mupuf_: want to adjust the phase?
13:58 karolherbst: it isn't that
13:59 mupuf_: I guess this can be improved by waiting for a certain value before reporting the value
13:59 karolherbst: or maybe it is
13:59 karolherbst: https://gist.github.com/karolherbst/f9deb77d60eb98794aec7c0b5f34c93b
13:59 mupuf_: yes it is
13:59 karolherbst: clock, pmu_load, nv_load
13:59 mupuf_: the problem is that I poll randomly
13:59 karolherbst: I think your forgot what you coded in it :p
14:00 mupuf_: and it is possible that cycles will be at 2% of what it should be
14:00 mupuf_: oh, did I code it in bash? :o
14:00 karolherbst: no
14:00 mupuf_: that would be surprising
14:00 karolherbst: c
14:00 karolherbst: but
14:00 mupuf_: so?
14:00 karolherbst: it does something else
14:00 karolherbst: it just sets the counter mode to 3 and to 0
14:00 karolherbst: depending on the interval
14:00 karolherbst: and then usleeps in between
14:00 mupuf_: ah,m right, sorry
14:00 mupuf_: wrong direction
14:01 karolherbst: yeah
14:01 mupuf_: yeah, you may increase the PWM rate if you want a higher accuracy
14:01 mupuf_: it is a parameter
14:01 karolherbst: I see
14:01 mupuf_: 1 kHz should be enough
14:01 karolherbst: it is 1 kHz
14:01 mupuf_: hmm
14:01 mupuf_: what accuracy do you need?
14:02 karolherbst: super high
14:02 karolherbst: I try 10 kHz
14:02 mupuf_: then you need to detect the frequency at which the pmu is polling
14:02 mupuf_: then you can let exactly how many cycles you should go through
14:03 karolherbst: 10 kHz looks better already
14:03 mupuf_: and then stop it until the value goes back to 0
14:03 mupuf_: do I make sense/
14:03 karolherbst: 1 kHz: "2300, 0, 14", 10 kHz: "2300, 0, 2"
14:03 mupuf_: say, you want 50% of load and you know it is polled at 10Hz
14:04 karolherbst: I will use 100kHz
14:04 karolherbst: mhh
14:04 mupuf_: then, you can set the mode to 3 for 50ms then off until the value goes back to 0
14:04 karolherbst: still not accurate enough
14:04 karolherbst: mhhh
14:04 mupuf_: dude, you are assuming the kernel can give you usleeps with such a great precision? :
14:04 mupuf_: You are dreaming :D
14:04 mupuf_: you need to do what I am saying
14:04 karolherbst: I need it
14:05 mupuf_: then do as I say
14:05 mupuf_: first detect the polling frequency, then let through as many cycles as you need before turning it off when the pmu polls your value
14:06 mupuf_: you'll get quite a good precision
14:06 mupuf_: then best you can
14:06 karolherbst: the latency is too big for it
14:06 mupuf_: ?
14:06 karolherbst: nvidia polls the value like real fast
14:06 mupuf_: how often?
14:06 karolherbst: 100Hz I think
14:07 mupuf_: then do as I say, you'll always get the highest accuracy
14:07 mupuf_: 100 Hz is still fine
14:07 mupuf_: the method I am proposing avoids the cumulative inacuracies of the Linux not being a perfect RTOS
14:08 mupuf_: (it is not even one :D)
14:09 karolherbst: I do it like that basically: set_mem_clock_offset; start the load faker; sleep 2; read_load; wait_until_load_faker_dead
14:10 karolherbst: the value of the memory counter is always 0
14:10 karolherbst: except what the faker messes with it
14:10 karolherbst: so it should be really irrelevant when I fake the load
14:10 karolherbst: also to get the timing right when nvidia resets all the values is quite difficult
14:11 karolherbst: and also adds latencies
14:11 mupuf_: this should be neglegible
14:11 mupuf_: we are talking about cycles at 200 MHz
14:11 karolherbst: true
14:12 karolherbst: but even faking a load of 0 produces too high counter values
14:13 karolherbst: allthough usleep is called with 0
14:15 karolherbst: nice -19 wtf :D
14:16 karolherbst: mhh, doesn't really help as well
14:16 karolherbst: okay, I will try to improve the tool
14:16 karolherbst: maybe it will make a significant difference
14:17 karolherbst: mupuf_: I think instead of doing usleep, I actually have to read out the current time and live adjust the time for the next sleep :/
14:18 mupuf_: karolherbst: and risk having Linux schedule you out because you are not nice to other processes
14:18 mupuf_:would trust linux here
14:19 karolherbst: I set the nice to -19 already, that process ain't nice :p
14:21 karolherbst: maybe time(); yield(); in the loop leads to more accurate results
14:28 mupuf_: lol, read up on yield "D
14:28 mupuf_: Seriously, usleep is pretty accurate
14:28 mupuf_: measure the jitter if you aren't convinced
14:36 karolherbst: uhh, meh, I know where the error comes from
14:37 karolherbst: timestamps in µs
14:37 karolherbst: 1482071802691180; usleep(0); 1482071802692232
14:37 karolherbst: :D
14:37 karolherbst: ohh wait
14:37 karolherbst: wrong one
14:37 karolherbst: 1482071802691125; usleep(0); 1482071802691178
14:38 karolherbst: that's 53µs for an usleep(0);
14:38 karolherbst: 2x printf + nva_wr32 takes around 2 or 1 µs
14:38 karolherbst: and 2x gettimeofday
14:39 karolherbst: 65µs for 10µs usleep
14:39 karolherbst: okay, there is always a 50µs latency
14:40 karolherbst: sooo, usleep is indeed not accurate enough
14:40 karolherbst: no idea what is going wrong here though
14:41 karolherbst: for a 1000kHz PWM that loop takes 1131 µs
14:41 karolherbst: sometimes more, sometimes less
14:42 karolherbst: it is in the range of 1110 µs to 1150 µs
14:42 karolherbst: saw a 1170 µs now
14:44 mupuf_: so, avoid stacking the errors on top of each others :D
14:44 karolherbst: :p
14:44 karolherbst: that's your code
14:44 mupuf_: well, works well enough for 1 kHz "D
14:44 karolherbst: I try it out with yield
14:44 karolherbst: :D
14:44 karolherbst: sure
14:45 mupuf_: at least on my machine
14:45 karolherbst: mhh
14:45 karolherbst: maybe my setup is borked
14:45 mupuf_: got ~1% accuracy
14:45 karolherbst: mhh
14:45 siro__: karolherbst: usleep sleeps for (at least) the time given, according to manpage
14:45 mupuf_: but the polling frequency was 10Hz
14:45 mupuf_: not 100
14:45 karolherbst: siro__: yeah well sure, but I want higher accuracy
14:46 siro__: busy poll a hardware counter
14:46 karolherbst: I do the yield thing
14:46 mupuf_: if you go a for busy waiting
14:46 karolherbst: yield + niceness of -19 should do the trick
14:46 mupuf_: then, go for the approach I proposed: detect the polling frequency
14:47 mupuf_: then just busy wait until you reach the value you want the PMU to read
14:47 mupuf_: and disable the counter
14:47 mupuf_: when it goes back to 0, increment again
14:47 mupuf_: that should take care of the phase difference
14:48 mupuf_: and now, I;m off
14:48 mupuf_: I am already 4h late
14:48 mupuf_: which is, by any standard, an offence
14:51 karolherbst: okay, it looks a bit better now
14:52 karolherbst: I am getting 1001µs with a 1kHz pwm now
14:52 karolherbst: per loop
14:53 karolherbst: huh, why does it busy wait allthough I use pthread_yield(); ...
14:53 karolherbst: ...
14:53 karolherbst: ohh wait
14:53 karolherbst: makes sense
14:53 karolherbst: I am stupid
14:55 karolherbst: nice, getting good values with a 1kHz pwm now
14:55 karolherbst: yeah :)
14:55 karolherbst: nice
15:12 karolherbst: mupuf_: by the way, usleep isn't part of POSIX anymore
15:13 karolherbst: there is nanosleep now
16:51 karolherbst: okay, this looks easy
17:22 karolherbst: mhh https://gist.github.com/karolherbst/c37361de0a98b9db5b5eb2acfb825b45
17:29 karolherbst: ohhh :O
17:29 karolherbst: nv_load = pmu_load * a / mem_freq_mhz
17:30 karolherbst: https://gist.github.com/karolherbst/c37361de0a98b9db5b5eb2acfb825b45
17:31 karolherbst: nv_load = pmu_load * 7050 / mem_freq_mhz
17:31 karolherbst: maybe it is 7000 and they just round oddish
17:38 karolherbst: mhh, couldn't nvidia print out more accurate values for a change :(
18:27 karolherbst: this looks good :) https://gist.github.com/karolherbst/8a3a2aaeddec4415e7cfced48de6e4af
18:27 karolherbst: but now I have to include the engine load to add
18:27 karolherbst: :(
18:30 karolherbst: huh, I thought the engine load affects this as well
18:31 karolherbst: ohh
18:31 karolherbst: it was the engine clocks ...
18:31 karolherbst: higher engine clocks, lower nv_load
18:32 karolherbst: OHHHHH
18:32 karolherbst: 7050 = 10 * 705
18:32 karolherbst: which was the clock I did the test
18:33 karolherbst: nv_mem_load = pmu_mem_load * 100 * (engine_clock / mem_clock)
18:35 karolherbst: *10 I meant
18:35 karolherbst: mupuf_: I am done reing how nvidia calculates the memory load :)
18:36 karolherbst: nvidia rounds towards nearest here by the way
18:46 karolherbst: mhh, but now I have to tell the pmu about the newest clocks :(
18:46 karolherbst: otherwise it doesn't know when to request a reclock
19:55 thican: Yo guys, do you know where I can find a tool like nvidia-smi?
19:55 thican: it's pretty nice
19:55 imirkin: 'sensors'
19:55 thican: but on my distribution, it's only available through the private drivers, which I can't have with my PaX kernel
19:56 thican: with nouveau, I only had voltage and temp
19:56 karolherbst: mhh
19:56 karolherbst: thican: which gpu?
19:56 thican: karolherbst: currently, I am on my 1050 Ti
19:56 karolherbst: it should at least also show the fan and power consumption
19:56 karolherbst: ohh mhh
19:56 karolherbst: don't know fi the 1050 ti has a sensors
19:57 karolherbst: thican: so it runs fine under nouveau now?
19:57 thican: I am sorry, I am ashamed of me, I installed the private drivers and gave up on my hardened kernel :-|
19:57 karolherbst: I see
19:57 thican: no, it does :'(
19:57 thican: *doesn't
19:57 karolherbst: bad you :p
19:57 karolherbst: well
19:57 karolherbst: X was the problem, right?
19:57 thican: indeed
19:57 karolherbst: would be nice to see the logs
19:57 thican: I will try to remember to give you data about the Xorg.log
19:58 karolherbst: do it now, so you don't forget it :p
19:58 thican: well, just a note, Nvidia's drivers can't have a correct resolution on TTY, while nouveau can
19:58 thican: karolherbst: you are mean, I have to reboot :-|
19:58 karolherbst: :D
19:58 karolherbst: well, the vbios would be also nice to have
19:58 karolherbst: /sys/kernel/debug/dri/0/vbios.rom
19:58 thican: vbios?
19:58 thican: ok
19:59 thican: about the sensors, I was talking about my previous GPU
19:59 karolherbst: I see
19:59 thican: the 8600 GT (nv86)
19:59 karolherbst: ohh right, we can't do power sensors there
19:59 karolherbst: it's only for fermi and newer
19:59 karolherbst: aka 400+
20:00 thican: I will check sensors too when I will reboot on nouveau
20:00 thican: power sensors, but I had the voltage while I was under my 8600 GT
20:00 thican: and the temp
20:01 thican: well, I’ll be back
20:04 thican: karolherbst: here for the Xorg.0.log https://thican.net/~thican/Xorg.0.log
20:05 thican: Oh, sorry, wrong kernel
20:05 thican: I reboot again ...
20:07 thican: but ...? It finally works O_o
20:07 thican: I am on X with nouveau
20:08 thican: with my 1050 Ti (GP107)
20:08 thican: I really don't understand …
20:08 thican: I might provide you my kernel config, if you want
20:09 karolherbst: mhh
20:09 karolherbst: shouldn't be needed
20:09 karolherbst: just the vbios.rom file
20:09 thican: I really don't understand …
20:09 karolherbst: check the X log :p
20:11 thican: karolherbst: https://paste.pound-python.org/show/uWo5LbatJZTWPolaLfyL/
20:11 thican: whuuuut? Why does Firefox see this? DescriptionVMware, Inc. -- Gallium 0.4 on llvmpipe (LLVM 3.9, 256 bits)
20:12 karolherbst: because you can't do opengl on nouveau with your 1050 yet
20:12 karolherbst: we need signed firmware files for this
20:12 thican: glxinfo https://paste.pound-python.org/show/ZCn4qp9J9bQqSGD4xUGu/
20:13 karolherbst: yeah, this is expected
20:13 thican: karolherbst: no, you need a key :-þ
20:13 karolherbst: this would be very counter productive
20:13 karolherbst: if we would find a way to just go around the signing mechanism, that would be fine
20:14 thican: So, I guess the drm-next (with my little modifications for GP107) is currently working
20:15 karolherbst: yeah
20:15 karolherbst: nice
20:15 thican: but I really don't like the stuff I see in red in dmesg (no color on this output, though) DescriptionVMware, Inc. -- Gallium 0.4 on llvmpipe (LLVM 3.9, 256 bits)
20:15 thican: sorry … https://paste.pound-python.org/show/2EtcubPE0xJ8wOj6oHC2/
20:16 imirkin: it's fine ... just means you don't get accel
20:16 imirkin: which is expected
20:16 karolherbst: mhh
20:16 karolherbst: BIT table A and L aren't found though
20:16 karolherbst: no idea what they do
20:16 karolherbst: :D
20:17 imirkin: those are fine too
20:17 karolherbst: k
20:17 thican: by the way, are those voltage values not destructive, right? :/
20:19 karolherbst: what do you mean?
20:19 thican: I saw ".volt = nv40_volt_new," in nv42_chipset
20:19 thican: but my bad, I tought it was in mine too
20:20 thican: I am just a bit scared it might harm the GPU, it's a gift from my friend
20:26 thican: Oh, it looks like I have less acceleration on this new GPU than my previous one, I have some errors about VDPAU and VAAPI with the media player MPV :/
20:26 karolherbst: yeah
20:26 karolherbst: expectged
20:26 karolherbst: *expected
20:27 karolherbst: pascal is still new and we have to deal with all those silly things
20:27 thican: I wish I could contribute in dev :/
20:27 thican: I saw the page wbout contributing
20:28 imirkin: unfortunately maxwell+ is unlikely to ever work well with nouveau, given nvidia's reluctance to release signed firmware.
20:31 thican: Isn't it inside the nvidia-driver archive?
20:31 thican: how could it work without it, then?
20:32 karolherbst: it is, somewhere
20:32 karolherbst: we didn't figure out where yet, though
20:32 thican: ok, good luck then :/
20:33 thican: Well, I live near this place: NVIDIA Development France SAS
20:34 thican: And because I have to do an internship, I might try this place
20:34 thican: (j/k)
20:34 karolherbst: don't try anything stupid though
20:35 thican: I know ;-)
20:36 karolherbst: I am serious though with no second meaning hidden
20:36 thican: I was obviously joking, like, what can I possible do in their department about mobile R&D?
20:37 thican: and I know the other place to eat almost every noon
20:37 thican: s/other //
20:38 thican: And I am interested in other fields, so …
20:39 thican: But still, I feel kind of spoiled … I add to remove some protection on my system to be able to use their drivers, and without it, I have a less working GPU than a 10 yo one.
20:39 thican: s/add/had/