00:19 karolherbst: skeggsb: any idea when you find some time to go over my reclocking patches? (now the right channel)
00:22 skeggsb: karolherbst: i'll try to take a look today
00:24 karolherbst: skeggsb: thanks. I really don't want to get this delayed more than 4.8, but I also know that it is quite a loot to look at
00:27 huelter: karolherbst, do you know if something changed for NVE4 from 4.5 to 4.6? It is much more stable now, 0 freezes so far
00:27 huelter: would be cool to know what did the trick
00:28 karolherbst: huelter: no clue
00:29 karolherbst: let me check
00:30 karolherbst: huelter: well, it might be that you have a PWM controlled GPU and on this you have a 6mV higher voltage on 4.6
00:31 huelter: cool, but I tried on 4.5 to up 100mV and it still froze
00:31 karolherbst: huelter: well, maybe some random instablity or something
00:31 karolherbst: no idea
00:32 huelter: nice, thanks :)
00:32 karolherbst: huelter: well you use the stock nouveau module right?
00:32 huelter: right now yes, but I tried your out of tree v4 on 4.5
00:34 karolherbst: no clue, I guess something might get fixed through other changes so, well I did nothing important for 4.6
02:47 mark4: is there any valid reason why a mouse would stop working after switching from nvidia-drivers to nouveau?
02:47 mark4: emerge -C nvidia-drivers
02:48 mark4: genkernel all --menuconfig and do nothing except enable nouveau
02:48 mark4: reboot. startx... mouse does not work
02:48 mark4: this happened with kernels 4.6.0- and 4.5.1
02:49 mark4: the horrendously crappy touchpad still works
02:50 mark4: i would really line to get a functional mouse in X if possible
02:51 imirkin: mark4: check xorg log?
02:53 mark4: would you like to see a paste of it?
02:53 mark4: i cant see anything in there that gives me a clue
02:53 mark4: i do know that plugging in or unplugging the mouse gives me appropriate events in dmesg and syslog
02:54 imirkin: pastebin probably
02:54 chithead: maybe nvidia card and usb controller share the same interrupt?
02:54 imirkin: unlikely.
02:55 mark4: https://bpaste.net/show/c44726454899
02:56 imirkin: so it finds a AlpsPS/2 ALPS DualPoint Stick and a AlpsPS/2 ALPS DualPoint TouchPad
02:56 mark4: yes
02:57 mark4: neigher of which is usable in world of warcrack :)
02:57 mark4: which YES does work under nouveau!
02:57 imirkin: do you have another device plugged in?
02:57 mark4: no
02:57 chithead: does /dev/input/mouse2 exist when you plug in the mouse?
02:57 imirkin: i'm confused by what the issue is then
02:57 mark4: mouse0 and mouse1 only
02:58 mark4: https://bpaste.net/show/0753a402e51f
02:58 mark4: paste of lsusb
02:58 mark4: mouse worked fine till i switched to novueau
02:58 chithead: then it is probably a kernel issue. pastebin "lsusb -t"
02:58 imirkin: do you have another pointer device plugged in?
02:59 mark4: no
02:59 imirkin: so what's the issue again?
02:59 mark4: https://bpaste.net/show/4da4d76bb662
03:00 mark4: i have no /dev/mouse2 only 0 and 1 for the clit and pad. the mouse pointer does not do anything when i wiggle the mouse
03:00 mark4: no movie at all
03:00 mark4: my xorg input devices are set to evdev and synaptics
03:00 imirkin: i find it hard to believe that'd be a nouveau issue
03:01 imirkin: perhaps you also changed your kernel?
03:01 chithead: please pastebin dmesg output when unplugging and re-pluggin the mouse
03:01 mark4: i was running 4.5.1 with nvidia-drivers. i tried to get nvidia-drivers working in 4.6.0 but they would not
03:01 mark4: so i switched to nouveau
03:01 mark4: mouse no workie
03:01 mark4: suggested i switch back to 4.5.1
03:01 imirkin: mark4: what about 4.5.1 with nouveau?
03:01 mark4: rebuilt kernel with the only change made was to enable nouveau
03:02 mark4: im in 4.5.1 now
03:02 mark4: mouse no workie
03:02 imirkin: and the trackpoint still doesn't work?
03:02 mark4: mouse pad and keyboard clit work fine
03:02 imirkin: please try to be precise with your naming
03:02 imirkin: trackpad and trackpoint work? do you have an external mouse as well?
03:02 chithead: google says to enable CONFIG_HID_HOLTEK
03:03 mark4: its the button shaped thing in the middle of the keyboad that moves the mouse according to the pressure you apply to it
03:03 mark4: i have no diea what its called
03:03 imirkin: right, i call it trackpoint - that's the IBM/lenovo name
03:03 chithead: as I understand it, touchpad and stick work, just the usb mouse doesn't
03:03 imirkin: the trackpad is ... the trackpad.
03:03 mark4: that was enabled when i was in 4.5.1 previously
03:03 mark4: the only change i made in menuconfig was to enable nouveau
03:03 mark4: period
03:03 imirkin: but then you have some *other* mouse plugged in?
03:03 mark4: NO
03:04 mark4: only the one thats not working
03:04 imirkin: so what exactly doesn't work?
03:04 mark4: the mouse
03:04 imirkin: you said both the trackpad and trackpoint work, and you have no other mouse plugged in
03:04 mark4: buttons dont do anything, moving it does not do anything
03:04 mark4: no. i said i have no OTHER mouses plugged in, i have this one that used to work just fine but no others
03:04 imirkin: so you do have an external mouse plugged in?
03:05 mark4: yes
03:05 imirkin: how is it connected?
03:05 mark4: usb?
03:05 mark4: lol
03:05 imirkin: i can't answer that question for you
03:05 chithead: imirkin: Bus 002 Device 007: ID 04d9:a067 Holtek Semiconductor, Inc.
03:05 mark4: it is plugged in via usb
03:05 mark4: which is why it shows up in the lsusb i pasted above lol
03:05 mark4: its the holtek device.
03:06 imirkin: how would i know that holtek is a mouse maker?
03:06 imirkin: anyways, looks like X isn't picking it up hence the issue
03:06 mark4: x picked it up before. why not now?
03:06 chithead: google for 04d9:a067 gives quite a few mouse related results
03:07 imirkin: dunno, you changed something other than enabling nouveau.
03:07 mark4: im double checking that the kernel option to enable holtek devices is still enabled
03:07 mark4: no
03:07 chithead: I think between 4.5.1 and 4.6.0 your kernel config changed in a way that makes it stop working
03:07 imirkin: quite clearly - yes.
03:07 imirkin: since your issue is in no way related to nouveau
03:07 mark4: genkernel all --menuconfig... device drivers-> graphics-> select nouveau
03:07 mark4: exit
03:07 mark4: rebuild
03:07 mark4: reboot
03:08 imirkin: diff a working kernel's config and a broken kernel's config
03:09 mark4: i have two kernels. 4.5.1 which used to work but no nonger does
03:09 mark4: and 4.6.0 which is a new install
03:09 chithead: please, less explain, more pastebin
03:10 mark4: i dont have a "working config" for it, the working coonfig was changed by enabling nouveau
03:10 chithead: then pastebin only the non-working config along with what was requested before
03:10 mark4: i only have one config for kernel 4.5.1 and thats the one post edit
03:10 imirkin: anyways, if you really truly think that nouveau is somehow responsible for this, build another kernel without nouveau and watch the mouse continue to not work
03:11 mark4: sec
03:11 mark4: that would mean a kenrel build and an nvidia install.
03:11 mark4: and im in the middle of rebuilding 4.5.1
03:12 mark4: i didnt make a change im just rebuilding
03:13 imirkin: pastebin your config
03:13 mark4: from /proc?
03:13 chithead: and your dmesg after unplug&re-plug
03:13 mark4: kk
03:13 mark4: does pastebin understand .gz files?
03:14 mark4: or should i copy it out and ungz it
03:14 chithead: zcat | wgetpaste
03:14 mark4: https://bpaste.net/show/8fe6b38d5c4f
03:14 imirkin: # CONFIG_HID_HOLTEK is not set
03:15 mark4: dafq
03:15 mark4: srsly the only change i made was in the video section to enable nouveau!
03:15 imirkin: perhaps a robber came and deselected that option when you weren't looking, and then vanished into the darkness
03:16 mark4: imirkin, the option that was previously set is not set now. that doesnt mean you have to be a dick about it. TY for the help
03:17 mark4: yes i was wrong, that option has been unset and had i bothered to look when you suggested it we would have been finished earlier
03:17 mark4: but i did NOT uncheck that option
03:17 mark4: the mouse worked in 4.5.1 under nvidia. all i did was emerge -C nvidia and enable nouveau
03:17 imirkin: i've never used genkernel, but i wouldn't be surprised if it didn't keep your old options at all
03:18 mark4: it does
03:18 mark4: in /etc/kernels
03:19 mark4: oh duh
03:19 mark4: no that still would not have given me a config to diff against
03:19 mark4: the one in /etc/kernels would be the same as the one in /proc
03:20 imirkin: anyways, dunno - i guess something might be off in your procedure then. i always just build a kernel directly without any wrapper scripts.
03:20 mark4: genkernel is the best way to go in gentoo, it creates the initramfs files too
03:20 mark4: simplificates thins
03:20 imirkin: i don't use a (dynamic) initrd either
03:20 mark4: thins
03:21 imirkin: which avoids annoying complications
03:21 mark4: you dont have /usr on a separate drive or partition do you :)
03:21 chithead: you can use genkernel initramfs with non-genkernel kernels (--no-ramdisk-modules)
03:21 mark4: which would be an annoying complication yes
03:21 imirkin: no, but if i did, it shouldn't matter
03:22 mark4: you need an initramfs if you want /usr on a separate partittion i belive now
03:22 imirkin: at least if things are properly put into /usr vs /
03:22 imirkin: anyways, i haven't had a separate partition for things in ages
03:22 imirkin: i used to do it back in the day, but i've decided it's a waste of my time
03:22 mark4: me either, i see no valid reason for it :)
03:22 imirkin: only time i use an initrd is when i do full-disk encryption
03:23 mark4: it was just an observation. your not using initrd files means /usr is on /
03:23 imirkin: but with that, it's not like it has to have kernel modules or anything like that
03:23 mark4: i really want to do that on all my drives on all my systems but its a huge pain to get working
03:23 imirkin: yeah, the first time was a pain, now i just copy it around :)
03:23 mark4: and ot for this channel :)
03:24 imirkin: good point.
03:24 mark4: my other laptop has 4 hard drives in it, all ssd's. two of them are msata running in raid 0 for my /
03:25 mark4: the other two are /home and a /home/data (place to dump large files i keep around)
03:25 mark4: i looked at encrypting those and... gave up after 3 days
03:27 mark4: actually teres something i didnt think of
03:27 mark4: maybe that option was NEVER set
03:28 mark4: even before... when the mouse worked
03:28 mark4: soon as i reboot after this rebuild we will see if switching that option on fixes things
03:35 mark4: ok so the mouse does work now
03:35 mark4: but i have a question
03:35 mark4: i was playing world of warcraft under wine and had my window size set to something i liked
03:35 mark4: previously the game played in any window size i set it to
03:36 mark4: now that i have switched to nouveau the game will not allow me to set a window size OTHER than valid SCREEN resolutions
03:36 mark4: i.e. 1024x768
03:36 mark4: 800x600
03:36 mark4: why?
03:38 mark4: why does window size have to match a valid vesa screen mode resolution?
03:38 mark4: why can i not set an arbitary window size ?
03:39 mark4: this meahs i get to play in a postage stamp sizeed window OR in a fully maximized i own the entire display mode and nothing else
03:39 mark4: neither option is acceptable
03:40 mark4: i can resize the window but tjat just rescales whats being displayed
03:40 mark4: and makes the aspect ration look stupid
03:50 imirkin: codegen/nv50_ir_ra.cpp:337: void nv50_ir::RegAlloc::BuildIntervalsPass::addLiveRange(nv50_ir::Value*, const nv50_ir::BasicBlock*, int): Assertion `bb->getFirst()->serial <= bb->getExit()->serial' failed.
03:50 imirkin: gr
03:50 imirkin: managed to trigger that in grid autosport =/
05:48 pmoreau: imirkin: Eh, good point! I removed it completely since I was doing high * low rather than high * high. Let’s see if it works better.
05:51 pmoreau: Yup, definitely some progress.
06:59 pmoreau: Gotcha! I didn’t thought I need to add the high bits from a.low * b.low… --"
07:09 Wonka: ouch ;)
07:17 pmoreau: And I had forgotten to lower the the add part of the MAD (since I was trying to get MUL to work). But now it finally works!
07:18 pmoreau: On the other hand, I was supposed to read articles and go to work… not to fix my patch… :-/
08:42 medfly: hi! sorry to ask a possibly off topic question. what is it called when you resize the actual monitor dimensions to size? I'm having some trouble on not-linux and I'm not sure what I am looking for in order to fix it
10:16 karolherbst: mupuf: weird, in the version 0x10 sense table there is no config for the sensors :/
10:17 karolherbst: ohh wait
10:17 karolherbst: actually when there is a valid extdev they do
10:20 karolherbst: awesome :)
10:21 karolherbst: all bios contain 0x07ff for the config, same value I currently set anyway
10:23 karolherbst: mhh what is 0x82 9x9c
10:24 karolherbst: *0x9c
10:37 karolherbst: noooo :/ are they friggin serious?
10:39 karolherbst: okay, this shit has variable lenght with bytes having different meanings depending on the length and there is nothing in the entry to tell us what they mean
10:39 karolherbst: mhh
10:40 karolherbst: 5 bytes general config// 2 bytes * res_count : resistor info // 2 bytes sensor config // N bytes garbage?
10:41 karolherbst: mhh maybe this:
10:42 karolherbst: 5 bytes general config// 2 bytes * res_count : resistor info // 2 bytes sensor config // 4 or 8 bytes unknown, if row length > 0x11 -> increase res_count
10:43 karolherbst: and now I found a counter example for this
10:43 karolherbst: ...
10:43 karolherbst: mupuf: shit, it seems like the parsing of the sense table entries depends on the extdev.type they link too :/
10:45 karolherbst: 01 00 00 00 00 05 00 05 00 00 00 07 68 00 00 00 00 => power rail 0: unk0 = 0x1, extdev_id = 0, shunt resistors = {5 mOhm (unk 0), 5 mOhm (unk 0), 0 mOhm (unk 0)}, config = 0x6807 // extedv[0].type == INA3221
10:46 karolherbst: 01 00 00 00 00 05 00 6f 0c 00 40 00 00 01 00 00 00 => power rail 0: unk0 = 0x1, extdev_id = 0, shunt resistor = 5 mOhm (unk 0), config = 0x0c6f // extdev[0].type == INA219
10:46 karolherbst: both version 0x20
10:47 karolherbst: why...
10:47 karolherbst: why they do this
10:52 karolherbst: I mean this is somewhat possible to handle quite easy in nouveau, but it is still ugly. In nvbios this adds some dependencies between P tables, which is really ugly there
10:53 karolherbst: ohh wait
10:53 karolherbst: extdev is no P table
10:53 karolherbst: funny
11:09 karolherbst: this will be fun then
11:10 RSpliet: karolherbst: it might help if we get the P tables in NVBIOS converted to the cleaner logic style
11:11 RSpliet: oh where does one get time :'(
11:11 karolherbst: they are
11:11 karolherbst: extdev is a DCB table
11:11 karolherbst: but it is also split between parsing and printing
11:11 karolherbst: but anyway
11:11 karolherbst: do we we want to depend on other tables while parsing?
11:12 RSpliet: if we have to, we have to
11:13 karolherbst: well I can cheat out of that using union { structs..., raw data array};
11:13 RSpliet: there's no cyclic dependencies between tables right?
11:13 karolherbst: no
11:14 RSpliet: good, and yes, unions are then the correct construct
11:14 RSpliet: but assume (and document in comments) a parsing order
11:14 karolherbst: well, the data is nearly the same, just the binary representation differes a bit
11:24 RSpliet: gnurou: wrt the hangs you encountered earlier, I have a branch that for me is rock-solid... but based on kernel 4.4
11:25 RSpliet: had it running OpenArena for four days at full speed on an NVE7, normally that would've crashed within a day
11:26 RSpliet: ... but the only difference with upstream is a massive calling convention enforcement change. If that solves the stability issue, then there's a bug hiding somewhere in plain sight that I bulldozered over
11:27 RSpliet: but feel free to try my branch -> https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/ctxswitch_litmus
11:35 karolherbst: RSpliet: I could do something ugly like this: https://github.com/karolherbst/envytools/commit/5538f159effe94a10d412e9febe6746d73e09a9b
11:35 karolherbst: RSpliet: you might want to update my commits :D
11:35 karolherbst: but I guess for testing it is enough for now
11:35 RSpliet: karolherbst: no
11:36 RSpliet: this kernel will stay as-is for the sake of reproducability of my experiments
11:36 karolherbst: ahh okay
11:37 RSpliet: resitor is a typo?
11:37 karolherbst: yeah
11:37 RSpliet: I'm not a huge fan of dragging in "raw" values
11:38 karolherbst: yeah, me neither
11:38 RSpliet: and I don't see a specific need for it either
11:38 karolherbst: well
11:39 karolherbst: it prevents dependencies in the parsing order
11:39 RSpliet: could you rephrase that please?
11:40 karolherbst: if I decide to parse the right thing at parsing time, I need to be sure that bios->extdev is ready
11:40 RSpliet: ah okay, no I think I got what you are trying to say
11:42 RSpliet: can you dump the output of nvbios -v for those tables please (so I can take a quick peek at the raw values)?
11:43 RSpliet: (I might prefer it to be an anonymous union btw, but that's a matter of taste. The "d" doesn't really clarify a lot)
11:47 karolherbst: RSpliet: some samples: https://gist.github.com/karolherbst/50571cd2f194f2e73477a32a591d6c13
11:47 karolherbst: RSpliet: especially gistfile4.txt and gistfile6.txt
11:49 RSpliet: hah, tnx
11:50 karolherbst: yeah, .. this table is just really badly designed
11:50 karolherbst: :D
11:50 RSpliet: it does what it has to do right?
11:50 karolherbst: :D
11:50 karolherbst: well
11:50 karolherbst: there are entries with subentries
11:51 karolherbst: I meant
11:51 karolherbst: tables
11:51 RSpliet: yeah, it would have been nice if they defined "3 subentries, 16 bits", but meh
11:51 RSpliet: I mean, technically to generate the timings from the timing table, you need to know the type of RAM - it's not as if we haven't seen dependencies before
11:51 karolherbst: they could just have a static size in front + subentries for each resistor
11:51 karolherbst: RSpliet: well. does the layout of the entries change depending on the ram type?
11:51 RSpliet: fortunately not
11:52 RSpliet: I mean, I see your point, but I guess an engineer just got overly eager with compressing his table in this case. there's no bad or good, just... annoying and easy :-P
11:53 karolherbst: ...
11:53 karolherbst: :D
11:53 karolherbst: those 2 bytes
11:54 karolherbst: I hope the 0x30 table will be better
11:55 RSpliet: hahaha
11:55 RSpliet: has skeggsb already pushed the VBIOS of his 1080? :-D
11:56 karolherbst: I checked daily
11:56 karolherbst: and no, he didn't
11:56 RSpliet: don't check, prod :-D
11:57 mupuf: RSpliet: ben is usually not using the vbios repo, AFAIK
11:57 mupuf: he has access to it though
11:57 RSpliet: (I pushed my GM107 VBIOS btw)
11:57 RSpliet: mupuf: okay, but sharing is caring :-P
11:57 karolherbst: RSpliet: yeah, I already saw that yesterday :p
11:58 RSpliet: ah good
11:58 RSpliet: I take it there's nothing exciting in there
11:58 karolherbst: well
11:58 Weaselweb: I'm running a GF119 using linux 4.6.0, mesa-11.2.2 and libdrm-2.4.68 and KDE plasma 5. after some time, when switching windows, the screen is not updated every time. I only see some flickering
11:58 karolherbst: 5 unknowns GPIOs
11:59 Weaselweb: even when window contents are updated, there is some flickering
12:00 mupuf: RSpliet: agreed :D
12:00 karolherbst: RSpliet: besides those GPIOs there is nothing interessting there I care about
12:00 Weaselweb: any idea what's wrong? I guess it is related to the plasma compositor using OpenGL
12:01 karolherbst: RSpliet: I think all 5 are internal anyway
12:02 karolherbst: > 0xb0 types
12:02 karolherbst: at least they aren't in the docs
12:03 karolherbst: RSpliet: and there is a semi-important fix in 4.6 for it
12:03 RSpliet: karolherbst: sorry, a semi-important fix for what?
12:03 karolherbst: RSpliet: voltage
12:03 RSpliet: ah good
12:03 karolherbst: well
12:03 karolherbst: increases the set voltage by 6mV
12:04 karolherbst: mupuf: any thoughts about the stupid sense table?
12:04 mupuf: well, not too surprised
12:05 karolherbst: RSpliet: anonymous unions are a GNU extension => I won't use them :p
12:05 RSpliet: are they? TIL...
12:05 karolherbst: RSpliet: yeah, it doesn't help that gcc defaults to gnu version of the languages by default ;)
12:06 karolherbst: mupuf: well it makes things silly enough :/
12:06 RSpliet: it's what you'd expect from a GNU C Compiler right?
12:07 karolherbst: well
12:07 karolherbst: I expect from a compiler that I write spec conform code
12:07 karolherbst: or at least that the compiler tells me I do something which I might shouldn't do
12:08 mupuf: karolherbst: agreed
12:09 mupuf: I hate that msvc encourages using non-standard extensions
12:09 mupuf: they should be disabled by default and enabled with a flag
12:09 karolherbst: well
12:09 karolherbst: for msvc it is kind of okayish though, because you don't write C++ by default with it anyway
12:09 mupuf: hehe
12:09 karolherbst: but VisualC++ (which is considered a dialect of C++)
12:09 karolherbst: :D
12:10 karolherbst: well
12:10 karolherbst: so does gcc default to gnuc and gnuc++...
12:10 karolherbst: anyway
12:11 karolherbst: if they change the default now, a lot of projects will just fail to compile
12:11 RSpliet: could be a fun experiment
12:11 karolherbst: well there is one hell of anoying GNU extension for variable static array sizes
12:12 mupuf: oh yeah
12:12 RSpliet: like the time Linus increased CLK_TICK to 1000 by default
12:13 karolherbst: :D
12:20 karolherbst: mupuf: any better way to handle this? https://github.com/karolherbst/envytools/commit/068fc24b55b7bdd4fe5446873eb2bd013666769c
12:21 karolherbst: I really don't want to add a dependency at parsing time, but if nobody is against it, I will most likely do it then
12:21 RSpliet: karolherbst: what's the content of "config"? can you and do you need to split it out into a bitfield?
12:22 karolherbst: RSpliet: config of the I2C device
12:22 karolherbst: as you guess, the meaning of the content depends on the sensors type ;)
12:22 RSpliet: I understand, but we know what it means right?
12:22 RSpliet: I mean, we have the datasheets for these sensors
12:22 karolherbst: yeah...
12:24 karolherbst: it is just a bit messy to parse those, because all bits mean something
12:24 karolherbst: and the fields are usually like 3 bits big
12:25 RSpliet: well, you can always make the assumption that your compiler doesn't reorder bit-fields. U-Boot gets away with it
12:29 karolherbst: I am not worried about that, just that if we parse that in nvbios we don't get much, because we don't plan to parse it
12:30 karolherbst: it just gets copied 1:1 into the i2c config reg
12:31 RSpliet: ah right, so the answer to my second initial question is "no" :-P
12:34 karolherbst: wow
12:34 karolherbst: so mayn 4.3 drivers now
12:35 karolherbst: where were we like 1 month ago? :D
12:37 mupuf: 4.1 for nouveau and radeon
12:39 RSpliet: karolherbst: yeah... about time to make it go faster :-P
12:40 karolherbst: mupuf: power rail 0: unk0 = 0x1, extdev_id = 1, shunt resistors = {5 mOhm (unk 0), 10 mOhm (unk 40), 10 mOhm (unk 40)}, config = 0x4e07
12:40 karolherbst: mupuf: resistor 2 and 3 don't exist
12:40 karolherbst: but I wonder why they have those values set
12:41 karolherbst: 0x40 bit might be for enabled/disabled or something
12:41 karolherbst: but the 10 mOhm is odd
12:41 karolherbst: I think I need to check out the titan today
12:41 karolherbst: now that I understood the layout of these friggin entries
12:43 karolherbst: mupuf: is reator down or something?
12:43 mupuf: shouldn't be
12:43 karolherbst: well either the URL changed or my internet connection sucks
12:43 karolherbst: where I would think it is the latter
12:44 karolherbst: but I get connection time outs
12:46 mupuf: ip must have changed
12:47 karolherbst: I see
12:48 iterati: hi. It's possible to change the clock if the card is running at non standard speed ? http://www.gigabyte.com/products/product-page.aspx?pid=4359#ov gtx650
12:48 karolherbst: iterati: why shouldn't it work if it has non standard speed?
12:49 iterati: karolherbst: I receive: nouveau 0000:01:00.0: clk: failed to raise voltage: -22
12:49 karolherbst: yeah
12:49 karolherbst: you need my patches
12:49 karolherbst: that's due nouveau isn't implementing the GPUBoost things right currently
12:50 karolherbst: and I have patches to fix that
12:50 iterati: karolherbst: where I can find those ?
12:50 karolherbst: iterati: https://github.com/karolherbst/nouveau.git
12:50 karolherbst: iterati: branch: stable_reclocking_kepler_v5
12:50 iterati: thanks
12:51 karolherbst: iterati: I figure you know how to deploy your own kernel or kernel module?
12:51 iterati: yeah, that won't be a problem
12:51 karolherbst: okay
12:51 karolherbst: well my branch is based upon 4.6
12:52 karolherbst: and you have to run make in drm and the output is in drm/nouveau/nouveau.ko then. The other stuff you should know then
12:53 karolherbst: iterati: well if you want you can give me the content of /sys/kernel/debug/dri/0/vbios.rom
12:53 karolherbst: iterati: and I could check if I missed something or something is different with your vbios I didn't handle yet
12:53 karolherbst: but the chances for this are rather low (I ope)
12:53 karolherbst: *hope
12:54 iterati: well, I'll see abnout it later... currently I am not wearing my lenses and can't see well :P
12:54 karolherbst: I see
12:54 karolherbst: iterati: well anyway, the gpu should clock much higher then those 1111MHz
12:54 karolherbst: 1058MHz is just the base clock of the normal one
12:54 karolherbst: and boosting usually gives you +100 - +150 MHz
12:55 iterati: even wwith the nvidia driver when they released the option to overclock it I was unable to do
12:55 karolherbst: it does so automatically
12:55 iterati: later, after drivers updates it became possible... so maybe it's a non standard clock or something
12:56 karolherbst: it is a bit more complicated then having just two clocks or something, but usually you have the base clock, and a boost clock, and then a lot of different clocks the driver selects the best of from
12:57 karolherbst: coolbits just add an offset to the selected clock wtihout adjusting the voltage (decreases stability)
12:58 karolherbst: the coolbit overclocking thing is just plain stupid and you have to be lucky to increase the clock by a significant amount
12:59 RSpliet: karolherbst: odds are you can overclock your DRAM with it easier than you can overclock your cores
12:59 iterati: yeah, the objective is to run it at normal speed and not the min
13:03 karolherbst: RSpliet: yeah well :D
13:03 karolherbst: iterati: you will be able to with my patches
13:03 karolherbst: hopefully
13:03 karolherbst: there are still some semi-stupid issues we have to figure out, but at least the clocking process itself should work
13:04 karolherbst: RSpliet: but true, nvidia allows me to overclock my memory from 4GHz to 8GHz...
13:52 imirkin: pmoreau: have a look at expandIntegerMUL() - i believe it does most/all of what you want
13:52 imirkin: pmoreau: it's a bit nv50-specific though
13:52 pmoreau: imirkin: It’s working now :-)
13:52 pmoreau: Or at least I haven’t found test data that made it fail :-D
13:53 pmoreau: But, I’ll have a look
13:54 imirkin: pmoreau: well, 64x64 -> 64 should be straightforward
13:54 imirkin: pmoreau: it's stuff like s32 x s32 -> s64 that's awkward
13:55 pmoreau: Hum, I haven’t tested that
13:55 pmoreau: I’ll try that tonight and see if it fails
13:55 imirkin: well, dunno if you have to support it
15:55 karolherbst: mupuf: any idea what we do about reading those sensors? I am sure nvidia knows from somewhere which channels are set on the INA3221, but I don't know from where
15:55 karolherbst: any ideas?
17:00 karolherbst: Tom^: seems like radeon also hits the csgo gunfire perf issue
17:07 hussam: karolherbst: hello. I have a question. under nouveau, with xf86-video-nouveau installed, any 3d game + gnome-shell keep using too high CPU but gtk+ apps work well. without xf86-video-nouveau installed, gnome-shell uses little cpu but CSD gtk+ windows fliker badly on resize.
17:07 hussam: is there any way to fix the xf86-video-nouveau issue?
17:07 karolherbst: no clue
17:08 karolherbst: I never ever looked into the ddx and don't intent do for now anyway
17:08 imirkin: hussam: that's odd ... i wonder if enabling DRI3 would help you? not sure.
17:08 imirkin: hussam: can you check with perf where the cpu time is going in the ddx?
17:12 hussam: imirkin: thank you. I will try enabling DRI3 in a bit. in the middle of a system backup now.
17:13 Tom^: karolherbst: i would say its valves fault
17:13 karolherbst: Tom^: :D
17:13 Tom^: karolherbst: because the performance drops overall on blobs too, just not as noticeable
17:14 karolherbst: Tom^: well the ratio is important
17:14 Tom^: karolherbst: the more annoying thing tho is that this has been around for soon 3 years now,
17:14 Tom^: ...
17:14 karolherbst: Tom^: when it drops only by 10% with nvidia but 40% with nouveau/radeon, then we should fix it
17:16 hussam: imirkin: Is this correct? http://pastebin.com/raw/pD0gws3R
17:16 imirkin: hussam: no
17:16 imirkin: hussam: man nouveau
17:17 hussam: Ah thank you. Option "DRI" "3" then
17:18 imirkin: right.
17:30 karolherbst: Tom^: try out the 32bit version :p
17:31 Tom^: im not so sure there is another cs:go version
17:33 karolherbst: Tom^: check the game folder
17:33 karolherbst: mupuf: any complaints about this bios/iccsense.h interface? https://gist.github.com/karolherbst/9b4b21d67a1fcfa4127e282dc071e280
17:34 karolherbst: mupuf: I will split those vbios rails according to the resistor count in the iccsense subdev anyway I think
17:34 karolherbst: just to stay flexible there
17:41 hussam: imirkin: enabling DRI3 fixed my issue. now gnome-shell no longer uses 30% CPU while idle.
17:42 karolherbst: sounds like tearing prevention went berserk
17:44 imirkin: hussam: awesome
18:03 hussam: karolherbst: If the fermi reclock patch doesn't apply when kernel 4.7 is released and I find it difficult to rediff it myself, would it be ok if I asked for help?
18:04 karolherbst: hussam: uhhh, well, the patch is pretty trivial in itself
18:12 karolherbst: but I think we should really upstream that memory/engine recocking flag split and enable one thing if it works
18:12 karolherbst: even if it doesn't increase performance that much
18:33 karolherbst: mupuf: do you got time to check reator=
18:58 karolherbst: reworked iccsense: https://github.com/karolherbst/nouveau/commit/9630aba387946098afc7c355cb35688f2a896c60
19:05 TTT: hi, does nouveau do power management? I have old laptop with 9300M gs, and it's overheating on Linux but not on Windows, with Mate & Nouveau
19:05 karolherbst: TTT: well it won't downclock by itself
19:05 imirkin: TTT: you can reclock manually on some GPUs... is that a G98? or MCP77?
19:06 karolherbst: gs should be G98
19:06 imirkin: karolherbst: hardly always :) they mess around with those things quite extensively
19:06 imirkin: TTT: anyways, what kernel are you on?
19:06 karolherbst: that's why I used the word "should" ;)
19:08 TTT: kernel 4.4.0
19:08 TTT: how do I manually downclock?
19:09 TTT: i mean what is the name of the command to do that?
19:09 imirkin: TTT: if you boot with nouveau.pstate=1 that will make a file appear in sysfs
19:09 imirkin: which will allow you to view the current settings and potentially modify them
19:09 TTT: right
19:10 TTT: I'll try that later today or tomorrow
19:14 karolherbst: mupuf: well reator still doesn't work ;)
19:15 dcomp: yay upstream recognisises my card ... which means I have to blacklist it as unloading it causes an oops
19:17 karolherbst: now that meas is branched, I can break all the things :)
19:21 imirkin: dcomp: you've got the broken vram right?
19:22 imirkin: [or rather, the vram that nouveau can't seem to turn on for some reason]
19:22 dcomp: imirkin: thats what ive been told
19:22 dcomp: i got so happy when i saw recognise gm108
19:23 imirkin: yeah sorry =/
19:50 hakzsam: imirkin, so, two weeks for fixing bugs :)
19:50 imirkin: usually more than 2 weeks...
19:50 imirkin: at least 3
19:56 hakzsam: well, june 10th is in two weeks :)
20:09 pmoreau: imirkin: If you are happy with the patch "nv50/ir: Add missing handling of U64/S64 in inlines" (I guess you don’t hate it since you added your R-b to it), could you please push it before we all forget that it exists? :-) I still don’t have a fdo account, though I plan to fix that tomorrow if I have time.
20:10 imirkin: pmoreau: patchwork link
20:11 pmoreau: imirkin: https://patchwork.freedesktop.org/patch/88117/
20:12 imirkin: pushed
20:12 pmoreau: Thanks!
21:10 karolherbst: mupuf: you know the one vbios with a INA3221 and INA219? according to the vbios the ina3221 has no rail :/
21:10 karolherbst: I am really wondering what we have to do there
21:11 karolherbst: but this makes a lot of more sense now :)
21:13 karolherbst: mhh
21:13 karolherbst: MAX6649
21:14 karolherbst: power rail 0: unk0 = 0x1, extdev_id = 0, shunt resistors = {5 mOhm (unk 0), 5 mOhm (unk 0), 5 mOhm (unk 0)}, config = 0x6607
21:15 karolherbst: this doesn't make sense for a ina3221
21:19 karolherbst: mupuf: the nve6 was the kepler you have, right?
21:48 imirkin: mwk: can you think of any good reason why if i have 32768 regs in the SM, and 1024 threads, i can only use 31 regs and not 32 in my compute program? i assume that $r63 wouldn't count in the usage?
22:01 imirkin: mwk: actually nevermind. it's likely a compiler bug.
22:01 imirkin: oh crap
22:01 imirkin: i think i know what it is
22:13 imirkin: yeah ok. spill register <-> predicate seems b0rked
22:17 karolherbst: and I hoped you found a serious perf issue where we don't use all regs from the SM :p
22:18 imirkin: instead i found a serious issue in our RA
22:18 imirkin: or spilling code
22:18 imirkin: or ... something.
22:19 karolherbst: mhh okay
22:20 karolherbst: currently I am seriously thinking about implementing a pass which marks the result of an instructions (signess, is 0, etc...) .. but then maybe it makes more sense to do GVN directly
22:21 karolherbst: not GVN, the other thing
22:23 imirkin: errr crap. those were supposed to be cc'd to stable. ugh