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