01:49karolherbst: mupuf: libnouveau is a cool thing :) I will do the voltage compare stuff with it, will do the voltage compare thing with it then
01:49mupuf: hmm, that can work too, yes. Make sure to mask every subdev you do not need!
01:50mupuf: because they are not meant to be ran along the blob
01:50mupuf: you can check my modified version of nouveau that dumps the clock
01:50karolherbst: I already get the voltage
01:50mupuf: it will tell you what to hide
01:51mupuf: yesterday, you asked me how to safely increase the accuracy of the PWM
01:51mupuf: well, you already know the answer, change the frequency in the vbios
01:51karolherbst: I want the blob to put the voltage into the pwm reg
01:51karolherbst: okay, but in the end the pwm will output 1.2V all the time, right?
01:52mupuf: don't make it so dramatic
01:52karolherbst: well 30% overvoltage shouldn't be that bad
01:52mupuf: you can try dividing by a factor of 2 the frequency
01:52mupuf: but do not run any 3D app with it
01:52karolherbst: yeah I know
01:53karolherbst: I also have to fake the temperature at some point
01:53karolherbst: at least I can put my fan to max through the bios
01:53mupuf: what is the point? It won't heat if you do not run anything
01:54karolherbst: ahh right, power gating and stuff
01:54mupuf: the only problem with lowering the frequency is that it won't react as quickly to a sudden change in the power consumption
01:55mupuf: and it will also confuse the shit out of the voltage controler because the input won't look as much as a fixed voltage but it will start oscilating
01:56mupuf: I guess it is fine as long as you do not use any 3D functions
01:56karolherbst: what would be the worst that could happen?
01:56mupuf: a brownout
01:56mupuf: you will need to reboot
01:56mupuf: that's it
01:56karolherbst: ahh okay
01:56mupuf: nothing worse than not setting the voltage too low
01:57mupuf: that should be fine, but do not be too extreme
01:57mupuf: a factor of 10 is the max should go down to
01:57mupuf: try going down slowish-ly
01:58karolherbst: well 10x accuracy isn't that much better though :/
01:59karolherbst: the divider is the problem in the end, isn't it?
02:00mupuf: well, sure
02:01mupuf: you will get it 10 times bigger by lowering the frequency by a factor of 10
02:01mupuf: if you can an order of magnitude in precision
02:01mupuf: that should be enough to get rid of rounding errors in a good-enough way
02:02karolherbst: 6.25 mV precision is pretty good though, I just hoped that I could bring the blob to put the exact 0.6V + xV value into the pwm reg
02:07mupuf: and how would you do that?
02:10karolherbst: by messing with the divider
02:11karolherbst: anyway, libnouveau seems to be enough in it's current state. I get the voltage, I get the gpc clock
02:11karolherbst: now I just need to map the clock to a cstate, get the voltage entry and see what voltage nouveau would calculate
03:49notaguest: I got a few NV0C gpus. where can I check the reclocking status of them? It's the quadro 1000m and the gtx560
03:58karolherbst: mupuf: daemon done :)
03:58mupuf: karolherbst: you mean you reworked your patches?
03:59karolherbst: no, I wrote the daemon to compare blob voltage with nouveau voltage
04:00karolherbst: you just run the daemon alongside the blob and it gives you the current set voltage on the hardware + what nouveau would set for the set pstate/cstate
04:06pmoreau: notaguest: This page (https://nouveau.freedesktop.org/wiki/PowerManagement/), or in the current status / news section of this ones (https://nouveau.freedesktop.org/wiki/) which might be kept more up-to-date.
04:08mupuf: karolherbst: Oh yeah
04:09karolherbst: current output: https://gist.github.com/karolherbst/2053d34a06ba8a353b63
04:09mupuf: now you can run it all the time and log discrepencies!
04:09karolherbst: ohh I should add the temperature
04:09mupuf: how about logging the diff, I hate doing those in my head
04:09mupuf: (absolute + %)
04:10karolherbst: yeah, will do that too
04:10karolherbst: I was busy with mapping clock => pstate/cstate :/
04:10mupuf: no worries!
04:10mupuf: and we can run that on other machines later
04:10mupuf: this is brillant
04:11karolherbst: though I don't respect the pstate voltage ranges yet
04:11mupuf: and better than what I was saying since you actually test nouveau's code
04:11karolherbst: that was the idea
04:11mupuf: you definitely need to talk about this work at XDC 2016 :p
04:17karolherbst: it works even with reading out the temperature
04:17karolherbst: I was worried, that the timer subdev messes the gpu up a bit with the blob running
04:28karolherbst: mupuf: timer subdev messes up the blob state :/ but it is required to get the temperature ...
04:29mupuf: ah, right
04:29karolherbst: ohh wait, maybe it isn't only the timer...
04:29mupuf: well, the timer is going to be a pain
04:29karolherbst: does fuse or i2c do something bad?
04:30mupuf: fuse, potentially, and same for i2c
04:30mupuf: you know what?
04:30karolherbst: with messed up blob state I mean it doesn't clock down anymore...
04:30mupuf: for your tests, just read the temperature by reading 20400
04:30karolherbst: good idea
04:30mupuf: and disable all the polling and everything
04:34karolherbst: https://gist.github.com/karolherbst/2053d34a06ba8a353b63 :)
04:37karolherbst: anything missing?
04:38mupuf: rel diff is in percent?
04:39karolherbst: or the other way around?
04:39mupuf: sounds good
04:39mupuf: well, document it :p
04:39karolherbst: its in the code :p :D
04:39karolherbst: well I just put a % in there and multiply with 100
04:39mupuf: if it is nouveau / blob, then being < 1 is a warning
04:40mupuf: and not acceptable
04:40mupuf: rel diff => ratio nouveau/blob
04:40mupuf: because it is not a difference
04:41mupuf: in any case, that looks like you are on good track
04:41karolherbst: being <1% close is pretty good though
04:41mupuf: you can make a sweep with force temperature
04:41mupuf: it is!
04:42mupuf: but as I said, a voltage that is under what hte blob does is a no-no for upstream
04:44karolherbst: ohh I think I have an issue somewhere in the temperature depending part
04:44karolherbst: above 72°C I am above nvidia
04:44karolherbst: there is something odd
04:45karolherbst: ohh I bet it is because of the stupid only int thing in the kernel
04:46Dezponia: karolherbst: Oh good. I was about to ask if it was gaining sentiance and starting an uprising
04:46karolherbst: Dezponia: it would be nice if you would run the daemon in the background later if you want
04:46karolherbst: it just verifies if the stuff I wrote is good or bad
04:46karolherbst: it's just a userspace daemon
04:47Dezponia: karolherbst: For the GTX780Ti/TITAN Black?
04:47karolherbst: I only have a nve6 card
04:47karolherbst: so there might be differences
04:47karolherbst: or maybe it is different for every card
04:47karolherbst: who knows
04:47mupuf: karolherbst: if you do computations using int64, make sure to use do_div for divisions
04:47mupuf: otherwise, 32 bits users are not going t be happy
04:48karolherbst: mupuf: those values aren't as big
04:48Dezponia: karolherbst: I'll poke at it if I have time this evening. I was planning on maybe doing it yesterday but insteed I had to work 2.5 hours overtime which was fun I guess :P
04:48mupuf: then use millidegrees instead of degrees when doing the computation :p
04:49mupuf: to avoid rounding errors with the temperature? :D
04:50mupuf: unless you mean that nvidia reads the temperature at a 0.5°C precision
04:50mupuf: which is possible because they have this information, but I doubt they do
04:50mupuf: because ... you know, it changes super quickly
04:51karolherbst: this looks odd: https://gist.github.com/karolherbst/2053d34a06ba8a353b63
04:51karolherbst: the jump from 72->71 °C
04:52mupuf: well, have fun, can't talk now
04:52mupuf: I got the results I was 2waiting for
04:53karolherbst: uhhh div by 0
04:53karolherbst: ohh no
04:53karolherbst: I don't do that
05:46karolherbst: k, so who had some kepler gpus crashing with higher pstates?
05:46karolherbst: mhh well I could test that on any kepler gpu actually
05:48mupuf: karolherbst: there is still the GK106 in reator
05:48mupuf: but ... it is GPIO-based, not PWM
05:49karolherbst: doesn't matter
05:49mupuf: still, you could test your tool on two cards there
05:49karolherbst: I would like to have some desktop like workloads
05:49karolherbst: but maybe it will be fine
05:50karolherbst: mupuf: do you know how to pass kernel parameters to libnouveau tools?
05:50mupuf: check out nv?init
05:50mupuf: now, have to go to my finnish class
05:51mupuf: and I barely haven't worked on it...
05:52vita_cell: karolherbst : is there still no reclock for gtx460 or 520gt?
05:52karolherbst: I don't work on the fermi cards yet
05:53karolherbst: I want to finish kepler first
05:53karolherbst: but what I currently do also helps fermi cards in the end
05:53karolherbst: (and maxwell)
05:53vita_cell: Kepler works very fine
05:53karolherbst: well for you maybe ;)
05:53karolherbst: but I know ways to still crash kepler gpus
05:53mupuf: vita_cell: nope it does not :D It may work by accident, but it is not full done ye
05:54mupuf: but it is getting close!
05:54vita_cell: I still using your patches on 4.3, and gtx770 works very good, no crashes
05:54karolherbst: vita_cell: do you use nvidia or nouveau?
05:54karolherbst: with my patches ;)
05:54vita_cell: I hate proprietary drivers
05:54karolherbst: vita_cell: you have this info.max volt hack, right?
05:55vita_cell: you did patches for me, volt fix stuff, and 3.0 patch, which is useless for me, because I am on i7-2600
05:56karolherbst: ahh pcie stuff
05:56vita_cell: I don't needes your patches anymore on 4.4
05:56karolherbst: none of them?
05:56vita_cell: deblobbed or blobbed 4.4 kernel I didn't need any patch, works out of the box
05:57vita_cell: tested it 4-5 times
05:57karolherbst: mhh then you are lucky
05:57karolherbst: wich means you may be able to overclock your gpu pretty much, but I still bet that lower clocks will crash your gpu
05:58vita_cell: Now I am on Mint, with 4.3, I needed to recompile nouveau.ko
05:59vita_cell: memory is 7009mhz, I think that more, will crash, but core is 1032mhz, I think that my GPU can get more
06:00vita_cell: 0f: core 405-1215 MHz memory 7010 MHz AC DC
06:00karolherbst: mupuf: 97.2% close on the kepler in reator
06:01vita_cell: most of games work very well, except Metro 2033 Redux
06:01karolherbst: gpio step is 0.025V?
06:01karolherbst: ohh 0.0125V
06:02mupuf: karolherbst: nice
06:02mupuf: here we go, bvulkan is out :)
06:02karolherbst: but but
06:02karolherbst: two days!
06:02mupuf: nope, it is the webinar in two days :p
06:03karolherbst: yeah I know
06:03karolherbst: I hoped they would release it then
06:08karolherbst: mupuf: stock nouveau: 88.3%, my volt fix: 97.2% :)
06:09mupuf: very nice
06:09karolherbst: but I bet some parameters are differnt for that card
06:10karolherbst: or maybe a parameter is used I don't respect yet
06:11karolherbst: ohhh T^2 parameter is set
06:14karolherbst: funny, the cstate set doesn't change through temperature, funny card :D
07:04pecisk: Vulkan API launched....yaaaay
07:19salamanderrake: does nouveau support vulkan yet?
07:26karolherbst: I would take a look, but the website is so overloaded, I think I may take a look after the webinrar
07:27phillipsjk: mpuf 0.5 degrees C is close to 1 degree F.
08:54karolherbst: mupuf: I sent out updated pmu counter patches
09:43karolherbst: those SENSE table entries are 21 bytes big :/
10:01karolherbst: mupuf: k, found the mapping byte for power_rail => extdev :)
10:39AndrewR: Hello, all! Finally got virgl working with qemu git + mesa git + xserver 1.18.1 (compiled with glamor support, for both host and guest) + kernel 4.5.0-rc3 on nv92!
10:40imirkin: cool. running with nouveau or blob?
10:41AndrewR: But ... there is some corruption ene for 2d (fluxbox) . I understand it uses modesetting + glamor + dri3 (and initially it failed for user because /dev/shm was not writable by user, in guest ... ) - but I wonder if this bug / glitch exist on other cards ...
10:41AndrewR: nouveau of course
10:41imirkin: well fwiw glamor is able to trigger some sort of bug in nouveau
10:42imirkin: i haven't been able to make any sense of it
10:42imirkin: but i have a "fix"
10:42imirkin: which basically kills perf
10:42imirkin: see https://bugs.freedesktop.org/show_bug.cgi?id=93373
10:43imirkin: oh except that won't help you on nv50
10:43imirkin: but you can do the same thing for nv50
10:43AndrewR: imirkin, I can't say perfomance is very good with athlon x2 3800 dual core (at 1.8Ghz) ....
10:43imirkin: in nv50_vbo.c - should be obvious
10:43AndrewR: imirkin, moment ..
10:43AndrewR: imirkin, qemu prints this into console (on host) http://pastebin.ca/3375002
10:50AndrewR: imirkin, basically put same command at same place? Just change IMMED_NVC0(push, SUBC_3D(NV10_SUBCHAN_REF_CNT), 0); to IMMED_NV50(..) ?
10:55AndrewR: few times qemu refused to load nouveau (with -22 error), so it was running on host's llvmpipe, I think, but I haven't tested it too much in this mode. But then ...I think artefacts were still here, so not completely nouveau's fault? Need to retest in this mode ...
10:57imirkin: AndrewR: sorry, BEGIN_NV04(push, SUBC_3D(...), 1); PUSH_DATA(push, 0);
11:07AndrewR: imirkin, will try this ...unfortunately with LIBGL_ALWAYS_SOFTWARE=1 on host I can't see those vertical thin lines on window border/titlebar in guest.
11:15AndrewR: imirkin, this one compiles ..lets try (need server rebot for more clean mesa install) http://pastebin.ca/3375014
11:36AndrewR: imirkin, unfortunately, hack also doesn't help.
11:40AndrewR: seamonkey (2.38) turned itself into this (under qemu/virgl): http://ibin.co/2XCIj5vhR9l8
11:40imirkin: so... almost right :)
13:01hakzsam: karolherbst, btw, if you have a gk110:gm107 chip, you might want to try MP perf counters. I have just sent a patch on mesa-dev for that :-)
13:01hakzsam: graphics ones are coming (still)
13:05imirkin: hakzsam: no more branches with sm35? :(
13:05hakzsam: imirkin, nope
13:05hakzsam: weird, I know
13:05hakzsam: but it doesn't seem to exist
13:05imirkin: that was my favorite one
13:06hakzsam: ask nvidia ;)
13:07karolherbst: hakzsam: I only have a nvc1 and nve6
13:08hakzsam: karolherbst, okay
13:10imirkin: hakzsam: btw, allegedly, GK20A uses the nve4 compute class
13:10imirkin: hakzsam: no clue if it's nve4 compute class but the shader is SM35
13:10imirkin: or if it's the much crazier option of both SM30 and SM35 support in one chip
13:11hakzsam: imirkin, GK20A is SM32
13:12imirkin: i don't know what that means
13:12imirkin: it uses the SM35 isa for graphics shaders
13:13hakzsam: so, it might support those MP perf counters
13:13hakzsam: I have never tested anything on gk20a
13:13hakzsam: and I don't plan to
13:14imirkin: it's not about supporting the right counters
13:14imirkin: it's about feeding a shader the right isa-encoded instructions :)
13:14hakzsam: oh okay :)
13:14imirkin: as-is your patch will try to feed it SM30 code
13:14imirkin: but i'm fairly sure it wants SM35
13:15hakzsam: imirkin, let me have a look
13:16imirkin: chipset == 0xea
13:16hakzsam: but does it really matter? coz I don't think anyone will use them :-)
13:16imirkin: then just disable it entirely
13:16imirkin: [no, it doesn't matter... nobody uses nouveau anyways]
13:19hakzsam: imirkin, yep, it will use the kernel compiled for SM30
13:19hakzsam: imirkin, actually, I might try because mupuf has a gk20a
13:22karolherbst: imirkin: when do you get time to test my mesa patches?
13:22imirkin: karolherbst: ugh i forgot... is there a tree somewhere?
13:22karolherbst: the neg(and(set)) and the saturate thing...
13:23karolherbst: not especially for those both
13:23imirkin: make a mesa tree
13:23karolherbst: the commits should be on my github repository usually though
13:23karolherbst: wait, I have to push recent stuff anyway
13:25karolherbst: ha! rebase helped me: https://github.com/karolherbst/mesa/commits/to_upstream
13:27karolherbst: imirkin: I think the neg(and(set)) opt has no big effect on the default shader-db stuff though
13:37karolherbst: mupuf: if (sense_table.row.bytes == 1) extdev = extdev_table.row[sense_table.row.bytes];
13:38karolherbst: seems to be valid for every vbios so far
13:38karolherbst: except one, which has no entries for its ina3221, but two for the ina219. (nve4/pecisk)
13:41karolherbst: for sense version 0x20 that is
14:20karolherbst: mupuf: okay, I think the rail is specified in byte 0x6 of the power_rail entry :) works for me, works for you, I will check others now
14:21mupuf: is that what I documented in my code?
14:21mupuf: for your previous assertion, this is exactly what I had in mind ... until seeing pecisk
14:21mupuf: and then all hell broke loose
14:21karolherbst: yeah but we had another issue
14:21pecisk: mupuf: huh? :)
14:21karolherbst: rail mapping to the three rails of the ina3221
14:22karolherbst: because for you byte 0x1 was 0 and 0x6 was 0 too
14:22karolherbst: for me, 0x1 is 0 and 0x6 is 1
14:22karolherbst: mupuf: your code modified by me: https://github.com/karolherbst/nouveau/commit/3f51d5474d5a409114ac573f7f0641072c290e66#diff-64c954cc3c197a46995a1c5782dcfe98R139
14:23karolherbst: r->rail is the 0x6 byte in the sense table row
14:23mupuf: hmm, well, that does not sound too bad
14:23mupuf: I will need to have a look at the code
14:24karolherbst: checking on reator now
14:24karolherbst: pecisk: wanna try something?
14:24karolherbst: ohh wait, I will check it first though
14:25karolherbst: skeggsb: can you add a "*.dwo" entry in .gitignore?
14:26karolherbst: skeggsb: it is debug symbol stuff from the linux kernel (if you enable some configs)
14:29karolherbst: mupuf: funny your gm107 has no power sensors?
14:30mupuf: karolherbst: sure, it is low-end, like all gm107
14:30mupuf: want the GM206?
14:30karolherbst: well, my code still works on your gk106
14:30karolherbst: well your code
14:30karolherbst: with my fixes
14:30mupuf: the only problem is ... no changes in the vbios :s
14:30karolherbst: doesn't matter
14:30mupuf: well, definitely make a v2 of it
14:30karolherbst: I just want to see if I still get the power consumption
14:30mupuf: should I plug it then?
14:31karolherbst: do you have another card with a power sensors?
14:31karolherbst: and 0x20 sense table?
14:31mupuf: nvc8 IIRC
14:31mupuf: not sure about the 0x20 sense table though
14:31karolherbst: let me check
14:31mupuf: c8 and ce
14:31karolherbst: c8 has 0x10
14:32karolherbst: ce also 0x10
14:32karolherbst: well then the gm206 card
14:32karolherbst: I don't have the vbios of it though
14:33karolherbst: mupuf: your nve4 please
14:34mupuf: I do noit think I have one :s
14:34karolherbst: well there is a nve4 vbios
14:34mupuf: wait a sec, I did not push my gm206's vbios or did you fail to update the vbios rtepo? :D
14:35karolherbst: I updated and didn't get it
14:36mupuf: it is there
14:36mupuf: two vbioses
14:36karolherbst: yeah, why stick to the naming scheme :p
14:36mupuf: exactly :D
14:36mupuf: well, we can decide what to do
14:36karolherbst: would be also good
14:36mupuf: but I guess sticking to nouveau's would be good
14:36karolherbst: I really want the gk104 :D
14:37karolherbst: 9 power_rail entries in the sense table for your gm206...
14:37karolherbst: but my idea works still: extdev 0 is the ina3221
14:38karolherbst: power rail 0: extdev_id/power_rail = 0, shunt resistor = 5 mOhm has 0x1 in 0x0 and 0x0 in 0x6
14:38karolherbst: so 0x0 rail of the ina gets the 5 mohm shunt
14:38karolherbst: this entry "power rail 1: extdev_id/power_rail = 1, shunt resistor = 5 mOhm" gets thrown away, because 0x0 byte is 0x0, not 0x1 as the above one
14:38karolherbst: and extdev_id 1 is garbage
14:40mupuf: well, that sounds good!
14:51karolherbst: mupuf: yeah, it is so 0x6 byte
14:52karolherbst: limitin power budgets to 15W: glxspheres 230 fps
14:52karolherbst: moding 0x6 byte from 0x0 to 0x1: 350 fps
14:52karolherbst: default perf: 350 fps
14:56karolherbst: furmark: 56fps default, 10 fps after reducing power budgets, 56 fps again after changing byte 0x6 from 0x0 to 0x1
14:56karolherbst: by the way, this benchmark just draws so much power from the gpu... it is insane
14:56karolherbst: even heaven is a joke compared to it
15:13karolherbst: mupuf: finished with switching gpus?
15:13mupuf: karolherbst: nope, sorry, plugging it right now
15:14karolherbst: k, thanks a lot
15:14mupuf: here ya go!
15:17karolherbst: mhhh.. "Direct firmware load for nvidia/gm206/fecs_inst.bin failed with error -2"
15:17karolherbst: anyway, it works for the other gpu
15:18karolherbst: power1: 18.56 W
15:18mupuf: yeah, some changes may be necessary
15:18mupuf: 18.56W sounds about right for nouvea
15:18karolherbst: ohh wait, I have to hook up the subdev
15:19karolherbst: ohh well I don't get any hwmon stuff for the maxwell one anywasy
15:23mupuf: you need to hide pgraph I would assume
15:23karolherbst: well it loads in the end
15:23karolherbst: but "iccsense ctor failed, -22"
15:24karolherbst: which is funny, because there is a sense table
15:28karolherbst: and now I get "nouveau: probe of 0000:05:00.0 failed with error -16" ...
15:28karolherbst: mupuf: k, then I would like to test the nve4 gpu too :)
15:37karolherbst: mupuf: well I am off to bed now anyway, will test tomorow then
15:40mupuf: hakzsam: will you need the gm107 tomorrow?
15:40hakzsam: mupuf, very probably
15:40hakzsam: mupuf, does karolherbst need it too?
15:41hakzsam: err, the gm206 I mean
15:42mupuf: not sure how long I will stay in the office tomorrow
15:42hakzsam: mupuf, okay, keep the gm206 for tomorrow then
15:42hakzsam: I'll do something else :-)
23:11gnurou: mmm, now that GM2 support is almost landed it would be nice to see the fans rotating on my card... :)
23:35gnurou: oh wait, don't tell me that the registers controlling the fans are protected... ?