02:26 pecisk: karolherbst: I tried your gddr5 patch, only switching to 0E blanked screen and froze machine, rest of switching happened without big pain. 0f cranked up memory speed but core stayed around 450-ish. Default mode ran xonotic on high settings on 30 fps, 0f run it on 60 fps (my monitor max allowed)
02:28 karolherbst: pecisk: is there anything bout voltage in dmesg?
02:28 karolherbst: like voltage failed with -22 error or anything?
02:29 karolherbst: also you can try out vblank_mode=1 which disables vsync
02:30 pecisk: one sec, I will report to my test partition
02:30 pecisk: bb
02:36 pecisk: karolherbst: I get this
02:36 pecisk: [ 264.913459] nouveau E[ CLK][0000:01:00.0] failed to raise voltage: -22
02:36 pecisk: [ 264.913462] nouveau E[ CLK][0000:01:00.0] error setting pstate 3: -22
02:36 karolherbst: pecisk: also the content of your pstate file please
02:36 karolherbst: mhh okay, maybe you have a PWM based card
02:36 pecisk: http://ur1.ca/nrqwu
02:36 karolherbst: pecisk: please install envytools and do "nvapeek 0x20344"
02:37 karolherbst: strange that 0e blanked your screen, but that may be related to something else
02:37 karolherbst: does switching to 0a works?
02:37 pecisk: yes
02:37 karolherbst: and the core clock changes?
02:37 pecisk: 980 Mhz
02:37 pecisk: one sec, paste
02:38 pecisk: AC: core 966 MHz memory 1620 MHz - I get this when I switch to 0a
02:39 pecisk: nvapeek command gives me three points ...
02:39 karolherbst: okay
02:39 karolherbst: then there is something odd for GPIO based kepler cards with the voltage
02:39 karolherbst: as a workaround you can switch to 0a first, then to 0f
02:39 karolherbst: this should give you a decent core clock as well
02:40 karolherbst: the gddr5 stuff isn't perfect yet, even with my patch, but we will get there
02:40 karolherbst: bad thing though, I can't help with that, because I have a laptop and gddr5 reclocking is already stable for me
02:42 pecisk: well switching from 0a to 0f froze machine, but I will try it fresh from restart
02:45 karolherbst: pecisk: mhh I wonder what the remaining problem might be :/
02:46 karolherbst: pecisk: I wonder if switching on the tty is more stable
02:46 karolherbst: would you like to try that out?
02:46 pecisk: well yeah, switching from 0a to 0f crashes
02:46 pecisk: okei :)
02:46 karolherbst: just do it a couple of times and check if there is a significant change in the amount of crashes
02:46 karolherbst: or artifacts or whatever
02:55 pecisk: ok, I did this three times, in second time it gave me screen with light green/blue lines and and those two lines about failure to set voltage which I usually get in dmesg when I try to switch to 0f
02:55 pecisk: but it was for few seconds and then it froze again
03:01 pecisk: I will try disable vsync, bb
03:05 karolherbst: pecisk: disabling vsync just gives you fps above 60
03:06 pecisk: I know, I just want to try something
03:14 karolherbst: k
03:14 karolherbst: and switching to 0f on a tty didn't change a thing?
03:20 pecisk: karolherbst: it was like before, it changed to 966 and 1620
03:21 pecisk: I pushed settings to ultra settings on xonotic, and I get 20 fps on default and 55 - 60 fps on 0f
03:25 karolherbst: pecisk: I meant switching to 0f on a tty
03:25 karolherbst: is it more stable to do on a tty
03:27 pecisk: karolherbst: ahhh, well, if I switch 0f first, then no, it works as in terminal
03:28 pecisk: well, it wasn't different from terminal - when I switched to 0a first and then 0f, it crashed all the same. If I just go stright to 0f, it's ok
03:30 pecisk: I will check agan switching to 0f, bb
03:34 pecisk: karolherbst: switcing to 0f in tty gives me those two lines about failed to raise voltage -22
03:34 pecisk: when doing it stright after reboot
03:36 karolherbst: yeah well, the voltage thing is another issue, which I currently not care about that much. If you are able to change to 0f more often on a tty it might to help others a bit as well in a workaround way
03:37 pecisk: karolherbst: do you mean change to 0f from other modes?
03:38 karolherbst: changing in general to 0f
03:38 karolherbst: if thats more stable on a tty, then it would be a nice information
03:39 pecisk: well, changing to 0f for me after fresh install is stable from both terminal and tty
03:39 pecisk: changing from 0a mode it crashes
03:40 pecisk: from both ways...so it is pretty consistent for me :) But I guess I can try to switch between modes and see if I can see any pattern that works
03:41 karolherbst: mhh okay I see
03:41 karolherbst: and changing fro 07 to 0e is also unstable?
03:42 pecisk: it is, but I will double check
03:42 pecisk: bb
03:43 karolherbst: I don't see any difference in your 0f and 0e, but maybe your bios will tell us more :/
03:43 karolherbst: its strange though
03:44 pecisk: karolherbst: ok, this is new...in tty switching from 0f to 0e didn't crash it
03:44 pecisk: directly going to 0e crashes it
03:46 pecisk: I will check 0f -> 0e in both terminal and tty
03:46 pecisk: bb
04:58 RandomRead: does anyone know how fragment shader invocations are handled in nouveau codebase? i mean how does it know how many times to run?
05:08 RandomRead: is it done transparently in hardware or is there some gpu command buffer method how iteration of the shader is generated say validation time?
06:34 mupuf: imirkin: anything noteworthy on the development of mesa since january 2014? So far I have the support for the ISA of the GK110/208, GM107. OpenGL 4.1
06:34 mupuf: and the performance counter work by samuel
07:05 mupuf: any ongoing developments for mesa too?
09:47 pmoreau:is getting completely confused about DataArray.\(acquire\|store\) regOnly and non regOnly mode, and memory handling in general NV50 IR...
11:19 imirkin: mupuf: noteworthy in what way?
11:21 mupuf: imirkin: noteworthy-enough to be in the status report gnurou and I will give at XDC
11:22 imirkin: hmmmm... not sure what the bar is. i guess GL 4.1 is kind of the big one.
11:23 imirkin: although note that GM107 support isn't super-great -- for one, i had to turn of tessellation
11:23 imirkin: off*
11:23 imirkin: for another, all the sched stuff is broken for it, which i suspect is the reason for the occasional glitches
11:39 RSpliet: mupuf: NVA0 reclocking? :-P
11:40 mupuf: RSpliet: it is in there :)
11:40 RSpliet: haha thanks
11:40 mupuf: imirkin: good to know for the GM107
11:40 RSpliet: although I should push out a patch asap to un-unenable it
11:41 imirkin: well, since jan 2014, that's also GT21x reclocking
11:41 imirkin: and maybe even kepler, forget when ben pushed his work
11:41 RSpliet: we covered that last XDC though
11:41 imirkin: mupuf: did you mean jan 2015?
11:41 mupuf: imirkin: no, I meant jan 2014
11:42 RSpliet: mupuf: do you have benchmark results?
11:42 mupuf: we have not had a status report since then. I agree though
11:43 imirkin: ok, looking through my commits to the docs dir...
11:43 imirkin: that should have relnotes changes
11:43 mupuf: oh, good idea the benchmark results
11:43 mupuf: imirkin: ye
11:43 mupuf: I had a look
11:43 imirkin: mupuf: ooh, looks like nv50 hit GL 3.3
11:43 imirkin: in early 2014
11:43 mupuf: yep, this is also documented :D
11:44 mupuf: oh, I did not mention which release
11:44 imirkin: 10.1
11:44 mupuf: which one was it?
11:44 imirkin: i also enabled a lot of the D3D10.1 features in the GT21x gpu's
11:44 RSpliet: imirkin: something VDPAUy as well?
11:45 imirkin: hmmmm... when did i get vp2 going?
11:45 imirkin: oh, but i bet that vp3/vp4 support on the tesla's happened in that timeframe as well
11:45 imirkin: (building on the existing support though, not as big of an achievement)
11:46 mupuf: ah, I did not check that
11:47 imirkin: other than that, all the stuff leading up to GL 4.1 support, which was a lot :)
11:47 RSpliet: how many commits touched nouveau in the first place?
11:47 RSpliet: (and how many of them, in promillages, were not imirkins in mesa, and not bens in kernel? :-P)
11:47 mupuf: imirkin: agreed, gl 4.1 is the biggest
11:48 imirkin: RSpliet: 549
11:48 imirkin: git log --since 2014-01-01 src/gallium/drivers/nouveau | grep '^commit' | wc -l
11:48 imirkin: *tons* of bugfixes too btw
11:48 mupuf: http://pastebin.com/ruPiGMGS
11:49 CapsAdmin: i'm having some issues detecting my second monitor. i uninstalled the proprietary drivers and installed the nouveau drivers and now the secondary monitor is gone
11:49 imirkin: mupuf: seriously? we added support for GM107 before GK110 isa?
11:49 mupuf: yop
11:49 mupuf: ben added support for the gm107
11:49 CapsAdmin: but even with the proprietary driver i had to do something to the xorg file. something to do with skipping signed something, i kinda forgot
11:49 imirkin: CapsAdmin: pastebin dmesg + xorg log
11:49 CapsAdmin: the monitor wasn't signed or something so it wasn't detected
11:49 CapsAdmin: okay
11:50 imirkin: mupuf: btw it's "support for", not "support of"
11:50 imirkin: mupuf: also GK110 and GK208 are the same isa...
11:50 mupuf: oh, thanks
11:51 imirkin: (SM35 in nvidia parlance)
11:51 mupuf: thanks, fixed
11:52 RSpliet: CapsAdmin: you might want to paste your Xorg.log and xrandr output
11:52 RSpliet: though a pastewebsite of choice
11:52 CapsAdmin: "dmesg xorg"
11:52 imirkin: i guess all the vdpau stuff happened before then. commit e01ba9d6b04 enabled it all in Dec 2013
11:52 RSpliet: and check whether you're running the Latest Greatest (tm) Linux kernel
11:52 CapsAdmin: can you be more specific? i'm not familiar with these commands
11:52 RSpliet: CapsAdmin: no, that's not how things work
11:53 RSpliet: /var/log/Xorg.0.log should contain the log
11:53 CapsAdmin: uname -r says 4.2.0-7-generic
11:53 RSpliet: (unless SystemD ate it)
11:53 RSpliet: that's late and great!
11:54 mupuf: we will share the slides when we have them sorted out
11:54 CapsAdmin: https://gist.github.com/CapsAdmin/1b16bfe432f40228ff81
11:55 CapsAdmin: tahts /var/log/Xorg.0.log
11:55 CapsAdmin: https://devtalk.nvidia.com/default/topic/788833/346-16-fails-to-set-edid-with-viewsonic-vx2260wm/
11:56 CapsAdmin: this was how i fixed it with the proprietary driver
11:56 imirkin: CapsAdmin: ok, look like you have a GM20x
11:56 CapsAdmin: " Option "IgnoreEDIDChecksum" "DFP-1" "
11:56 imirkin: CapsAdmin: how is the second monitor connected?
11:57 imirkin: is one on DVI-I-1 and the other on DVI-D-1?
11:57 imirkin: CapsAdmin: grep . /sys/class/drm/card*-*/status
11:57 CapsAdmin: with a dual link dvi cable using an adapter to mini display port i think
11:57 CapsAdmin: sys/class/drm/card0-DP-1/status:disconnected
11:57 CapsAdmin: sys/class/drm/card0-DP-1/status:disconnected
11:57 CapsAdmin: sys/class/drm/card0-DP-2/status:disconnected
11:57 CapsAdmin: sys/class/drm/card0-DP-3/status:disconnected
11:57 CapsAdmin: sys/class/drm/card0-DVI-I-1/status:connected
11:57 CapsAdmin: sys/class/drm/card0-HDMI-A-1/status:disconnected
11:57 imirkin: please use pastebin for more than 2 lines in the future.
11:58 CapsAdmin: okay
11:58 imirkin: ok, so it's not detecting your DP one... some fixes went into 4.3 for maxwell DP stuff
11:58 CapsAdmin: should i test 4.3?
11:59 CapsAdmin: and did you see the solution for the proprietary driver about the edid checksum thing? (hoping that gives some clues)
12:00 imirkin: well, you never provided dmesg, which i think would show such issues
12:00 CapsAdmin: oh, well i wasn't sure what commands to run
12:00 imirkin: "dmesg"
12:00 CapsAdmin: okay
12:01 CapsAdmin: dmesg: https://gist.github.com/CapsAdmin/c9250f55d21b44173118
12:02 hakzsam_: mupuf, nv50 doesn't expose gl_amd_perfmon yet, btw
12:02 imirkin: [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid
12:02 imirkin: aha, so it's, uh, working
12:02 imirkin: nouveau 0000:01:00.0: DP-3: EDID block 0 invalid
12:02 mupuf: hakzsam_: ah, ok. I will move it then
12:02 imirkin: now... to remember how to disable that
12:02 imirkin: airlied: --^
12:02 imirkin: remember offhand?
12:03 CapsAdmin: so the temporary solution given by nvidia with the proprietary driver was to just ignore the checksum
12:03 CapsAdmin: dunno about a real solution though
12:04 CapsAdmin: the nvidia driver generated some xorg config files so i was able to just put it in there easily but now i'm not sure what to do
12:04 CapsAdmin: and it'd be nice if it was fixed for real
12:05 imirkin: CapsAdmin: no, that's a real solution ;)
12:06 imirkin: it's just very rare that this happens and i don't remember offhand how to deal with it
12:06 CapsAdmin: what could be the cause? shady cable?
12:07 imirkin: or shady monitor
12:07 CapsAdmin: lol
12:07 imirkin: or, more likely, shady DP -> dual-link DVI active adapter
12:08 imirkin: since that's where the EDID is ultimately coming from
12:09 imirkin: you could, instead, get a passive DP -> DVI (or HDMI -> DVI) adapter, and that should support your 1680x1050 screen just fine
12:09 imirkin: and the built-in DVI-I-1 port should be dual-link capable
12:09 CapsAdmin: is there a way to disable this checksum thing system wide? what's the purpose of this checksum thing in the first place?
12:09 imirkin: retrieving the DDC is done over i2c, there's no built-in error correction
12:09 imirkin: checksum is to make sure it got transfered ok
12:10 glennk: once upon a time you had CRTs which could give up the magic smoke if you programmed a mode far enough outside its range
12:10 CapsAdmin: i'll have to figure out how to generate the xorg config file but even then i'm not sure if the undetected monitor will be there. the nvidia driver at least somewhat detected it
12:11 CapsAdmin: but i was only able to use a very small resolution
12:11 CapsAdmin: ah lol
12:14 tobijk: mh i wanted to ask if that monitor is coming from standby...
12:15 tobijk: maybe its hardware is too slow :D
12:16 tobijk: imirkin: feel poked for still not commiting the glamor removal :P
12:18 CapsAdmin: so if i stop sddm and run X -configure i get "Number of created screens does not match number of detected"
12:20 CapsAdmin: oh it was generated to home/xorg.conf.new
12:20 CapsAdmin: is this just an output or will it be used?
12:21 tobijk: CapsAdmin: the one from /etc/X11 is used as far as i know
12:21 CapsAdmin: so i should move this file there then and remove ".new"
12:22 tobijk: CapsAdmin: the xorg log telsl you which one it is using though
12:22 tobijk: *tells
12:27 tobijk: thx :)
12:27 imirkin: errrrr
12:27 imirkin: gr
12:27 imirkin: forgot to build test :(
12:27 tobijk: i can do that, np
12:28 imirkin: no
12:28 imirkin: it's broken
12:28 imirkin: i'm fixing it :(
12:28 tobijk: :/
12:29 Yoshimo: imirkin: why are you removing support? Bad quality?
12:30 tobijk: Yoshimo: it is partly and with xserver 1.18 it does not even compile anymore :/
12:30 imirkin: Yoshimo: bad quality of integration, and there's no reason to use nouveau + glamor over modesetting + glamor
12:31 Yoshimo: no reason to keep it around if it won't compile indeed
12:31 imirkin: well it could certainly have been fixed
12:31 imirkin: just... no point
12:35 tobijk: imirkin: ok that version compiles fine for xserver 1.18 now :)
12:35 imirkin: great
12:56 imirkin: mupuf: you might be interested in e.g. http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#b=version&g=NVIDIA%20GKxxx%20(GeForce%20600%2C%20700)
12:56 imirkin: (use the dropdown to select other gpu's)
12:57 imirkin: and if you deselect vendor, you can also enable the diff mode
13:10 pmoreau: imirkin: How can I get the TGSI code of a shader? I remember you told me to use piglit and to write a shader_test, but I forgot the remaining... :/
13:12 imirkin: NV50_PROG_DEBUG=1
13:12 imirkin: it'll get spit out at the top
13:12 pmoreau: Right, but what was the command to run on the shader_test?
13:12 imirkin: bin/shader_runner foo.shader_test
13:12 imirkin: -fbo -auto
13:13 pmoreau: Ah!! Right!
13:13 pmoreau: Thanks! :-)
13:42 CapsAdmin: i'm not sure how to do this. i put the generated xorg.conf.new file in the appropriate place (regardless of the number of created screens does not match number of detected" error) and put Option "IgnoreEDIDChecksum" "DFP" in the screen section as it was in the previous conf
13:43 CapsAdmin: using "Display Configuration" that comes with KDE
13:43 CapsAdmin: xrandr says it's disconnected
13:48 imirkin: afaik the only way is to supply an approriate edid
13:48 imirkin: look into the edid_firmware kernel option
13:59 karolherbst: airlied: okay, your patch seems to "kind of" work
14:00 karolherbst: but while loading nouveau, the scree freezes and I am not sure if that's X fault or kernel drm, but I assume the former, because it didn't happen before
14:00 karolherbst: also look at those lines: [ 205.315] (II) xfree86: Adding drm device (/dev/dri/card1)
14:00 karolherbst: [ 229.990] xf86: found device 1
14:00 karolherbst: I have some nasty timeouts while loading nouveau, that's why there is a big time difference
14:19 airlied: karolherbst: that patch should just stop X doing anything with the devices, they'll still show up on it's probe
14:19 karolherbst: yeah, this part works
14:19 karolherbst: but somehow X seems to "detect" the card for a long time
14:19 karolherbst: until it is finished with "detecting" the card
14:20 karolherbst: and in the meantime, X freezes
14:20 karolherbst: I actually noticed this behvaiour before alteady
14:21 karolherbst: *already
14:22 airlied: karolherbst: hmm oh we still must open the device to get some info from it
14:22 airlied: which causes it to delay I suppose
14:24 karolherbst: yeah, usually this shouldn't be a problem, because nouveau should load in under a second
14:25 karolherbst: but I have to use a dirty hack and modprobe/insmode needs around 15 seconds after they are done
14:31 karolherbst: airlied: I guess that device detection isn't done asynchron and the server does nothing until the device was fully "discovered"
14:33 karolherbst: anyway, even DRI_PRIME offloading works that way, so its somehow fine for me already, allthough the freeze is a bit annyoing
14:55 pecisk: karolherbst, just last followup for my little mode switching experiment - restart -> 0f -> 0e works, restart -> 0f -> 0a -> 0e crashes (similar to 0a -> 0f). Only difference between 0e and 0f is that I can go to 0f straight away
14:56 karolherbst: pecisk: mhhh
14:56 karolherbst: pecisk: could you put your vbios somewhere?
14:57 karolherbst: would like to take a look
14:59 imirkin: pecisk: fwiw we don't print the full pstate info
14:59 imirkin: there could well be other differences
14:59 karolherbst: pecisk: "/sys/kernel/debug/dri/1/vbios.rom"
14:59 pecisk: karolherbst, just copy it?
14:59 karolherbst: mhh
14:59 karolherbst: this path: /sys/kernel/debug/dri/0/vbios.rom
14:59 pecisk: ok
14:59 pecisk: bb
14:59 karolherbst: its some binary stuff
15:00 tobijk: karolherbst: it can be both paths :>
15:00 karolherbst: better xz it and use some file hoster stuff
15:00 tobijk: *one of them
15:00 karolherbst: tobijk: he has a desktop card
15:00 tobijk: ah nvm
15:01 karolherbst: imirkin: his clock is also like 16MHz higher then the pstate tells him for 0a
15:01 karolherbst: seems like something is messed up for core clocks as well
15:05 pecisk: karolherbst: vbios.rom file here https://drive.google.com/file/d/0B31QWsnd2TuWVFBuQXZ6dmRqT1E/view?usp=sharing
15:06 karolherbst: pecisk: what card was it again?
15:06 pecisk: karolherbst: 760 GTX
15:06 karolherbst: okay
15:06 pecisk: 01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1)
15:09 karolherbst: ohhh wow, mupuf this one will make you crazy :D
15:09 karolherbst: -- Mode GPIO, Base voltage 825000 µV, voltage step -12500 µV, acceptable range [825000, 1212500] µV --
15:09 karolherbst: mhhh
15:09 karolherbst: no 5.0 pcie mode
15:09 karolherbst: strange
15:09 karolherbst: wait a moment
15:10 karolherbst: okay, from a deeper look 0f and 0e seems to be identical
15:10 karolherbst: imirkin: can there be a difference not shown in the vbios?
15:12 imirkin: no
15:12 imirkin: but there can be things we don't parse properly
15:13 karolherbst: I see
15:13 pecisk: I wonder what makes 0f to pass trough and 0f to lock...However 0f doesn't crank up core, just memory
15:13 pecisk: 0f/0e/s
15:14 imirkin: pecisk: does your card actually have a stereo connector??
15:14 imirkin: (for 3d glasses and the such)
15:14 karolherbst: imirkin: what is this "Voltage entry" about in the PM_mode tbale?
15:14 imirkin: i thought those had been entirely outmoded
15:14 karolherbst: it's the only difference I currently see
15:15 karolherbst: but both voltage entries seems to be identical
15:15 karolherbst: but nouveau couild "use" them wrongly
15:15 pecisk: imirkin: stereo? I have two DVIs, one HDMI and Display port if I remember
15:15 pecisk: can't look behind, too dark atm :)
15:15 imirkin: pecisk: https://en.wikipedia.org/wiki/VESA_Stereo
15:16 imirkin: i have a NV42 here with one
15:16 imirkin: but afaik by the time G80/etc hit, they were already dying out
15:16 karolherbst: mhh, the vbios seems usually pretty sane
15:17 karolherbst: ohhhh, wait
15:18 karolherbst: mhh strange?
15:18 karolherbst: pecisk: which patch did you use for gddr?
15:19 karolherbst: I thought my clock adjustemen should be pretty close now, but its still 40MHz higher than expected?
15:19 pecisk: karolherbst: your gddr5 branch, cloned git repo and git checkout gddr5
15:19 karolherbst: mhh
15:19 karolherbst: strange
15:19 karolherbst: I was sure I did it right
15:19 karolherbst: pecisk: when did you do that?
15:19 pecisk: karolherbst: yesterday
15:20 karolherbst: mhhh
15:22 karolherbst: pecisk: when you are at 0f, could you paste the output of nvapeek 0x132000 0x40
15:22 pecisk: k
15:22 pecisk: sec
15:22 karolherbst: and nvapeek 0x137330
15:23 mupuf: karolherbst: hmm, what the heck? Why is the voltage step negative if the base voltage is 825000
15:23 pecisk: first paste
15:23 pecisk: 00132000: 98030001 00001c03 10000000 00000000
15:23 pecisk: 00132010: 00000000 00000fff 00000000 00000000
15:23 pecisk: 00132020: 20030001 00032301 f0000000 00000300
15:23 pecisk: 00132030: 10001007 0a3e1000 00000000 00000000
15:23 karolherbst: mupuf: what me to push the vbios?
15:24 mupuf: karolherbst: yeahm please push
15:24 mupuf: and ask for nvapeek 101000
15:24 mupuf: I need the strap peek quite often
15:24 pecisk: second paste 00137330: 81200634
15:25 pecisk: mupuf: nvapeek 101000 gives me 00101000: 80405c96
15:30 karolherbst1: weird
15:31 karolherbst1: pecisk: you are not using my patch
15:31 karolherbst1: basically
15:31 pecisk: hmmmm
15:31 karolherbst1: how did you install the module?
15:32 karolherbst1: mupuf: pushed it
15:32 pecisk: karolherbst1: cd nouveau/drm; make
15:32 karolherbst1: yeah well, that won't install the module
15:32 pecisk: karolherbst1: and make install afterwards of course
15:33 karolherbst1: well
15:33 RSpliet: pecisk: depending on the distribution you use, that still doesn't make your system use the module
15:33 karolherbst1: it goes into extra I guess
15:33 RSpliet: eg. on Fedora you need to regenerate your initramfs
15:33 karolherbst1: /lib/modules/$kernel/extras
15:33 pecisk: karolherbst1: modinfo nouveau shows me using nouveau.ko from extra directory, which both created yesterday
15:33 RSpliet: okay
15:34 pecisk: one sec
15:34 karolherbst1: which is not important
15:34 karolherbst1: modinfo tells stupid stuff
15:34 pecisk: http://ur1.ca/nrx88
15:34 karolherbst1: its also wrong for me
15:35 karolherbst1: pecisk: remove all nouveau.ko files
15:35 pecisk: how to ensure system uses it instead of installed one?
15:35 pecisk: k
15:35 pecisk: bb
15:35 karolherbst1: and then move the nouveau.ko into kernel/drivers/gpu/drm/nouveau/
15:35 RSpliet: pecisk: here's what you do: copy the module to /lib/modules/4.2.0-9001.fc22.x86_64/kernel/drivers/gpu/drm/nouveau/
15:36 RSpliet: rename or move the original nouveau.ko.xz out of the way
15:36 RSpliet: run "strip -S nouveau.ko" to shrink it
15:36 pecisk: k
15:36 RSpliet: then "xz nouveau.ko"
15:36 RSpliet: followed by "dracut --force" to regenerate initramfs
15:36 pecisk: RSpliet: just curious what strip does?
15:36 karolherbst: remove uneeded stuff
15:37 RSpliet: removes reference tables
15:37 RSpliet: excessive debugging information
15:37 RSpliet: that kind of stuff
15:37 RSpliet: oh, replace your own kernel version into that path btw
15:37 RSpliet: (mine is over 9000, yours probably isn't)
15:37 pecisk: sure
15:38 karolherbst: fancy 4.2 kernel you got there :p
15:38 RSpliet: yes, esp. considering it comes from kernel-core-4.3.0-9001[...].rpm
15:39 RSpliet: don't ask
15:39 karolherbst: :D
15:39 pecisk: ok, rebootin
15:39 pecisk: I have 300 there :p
15:39 karolherbst: and I was like thinking, why is his memory clock so much higher
15:40 RSpliet: yes, I usually go for a number high enough not to be replaced by intermediate fedora updates
15:40 karolherbst: I think the core clock PLLs are also buggy
15:41 karolherbst: 405->980, allthough he should got 967MHz
15:41 RSpliet: if you mean the coefficient generation routine in nouveau is buggy then maybe
15:41 karolherbst: yeah, maybe
15:41 karolherbst: I think nouveau just tries to adjust from the old value
15:42 karolherbst: instead of calculating from scratch
15:42 karolherbst: was the same issue for gddr5 kind of, too
15:43 RSpliet: oh dear, pecisk is taking an awful long time to reboot
15:43 karolherbst: oh well
15:44 karolherbst: isn't there some kind of fallback?
15:44 RSpliet: pick a previous kernel
15:44 RSpliet: in grub
15:44 karolherbst: :D
15:44 karolherbst: oh well
15:44 karolherbst: no efifb or anything?
15:45 RSpliet: well, he might get something like that, but if then Xorg is hard-wired to nouveau in xorg.conf it doesn't matter much
15:45 karolherbst: ....
15:45 karolherbst: :D
15:45 karolherbst: shit
15:45 karolherbst: maybe he is smart enough and reinstalls the kernel from tty or something
15:45 RSpliet: nah, just boot an older kernel and he'll be fine
15:47 pecisk: you can't really trust modinfo :/
15:47 karolherbst: I told ya
15:47 RSpliet: as far as you can throw it
15:48 karolherbst: pecisk: so whats up
15:48 pecisk: I can't load that module due of sitting on fedora 23 and it has kernel-headers with +debug attached, while version magic requires without it
15:48 karolherbst: uhhh
15:48 karolherbst: sounds awesome
15:49 RSpliet: pecisk: hmm, you have a debug kernel installed?
15:49 pecisk: no
15:51 RSpliet: sounds odd then... no kernel-headers-debug right?
15:51 pecisk: nope, just kernel-headers
15:52 pecisk: I have kernel-debug-devel but it seems to be unrelated package needed by some other devel packages
15:52 RSpliet: oh... hmm, yes, you probably grabbed a kernel from koji with debugging enabled
15:52 karolherbst: mhhh
15:53 karolherbst: this should be fixable though
15:53 RSpliet: I wait... hmm, no
15:53 karolherbst: ohh wait
15:53 karolherbst: "$(shell uname -r)" should give the right info, right?
15:53 RSpliet: the Fedora kernel package/release system is interesting
15:54 karolherbst: should we adjust KVER?
15:54 karolherbst: I meant, KDIR
15:54 RSpliet: probably not
15:54 karolherbst: mhh right, make should build against the currently running kernel anyway
15:55 pecisk: RSpliet, well, it can be reason because this was TC for beta 1 for Fedora 23
15:55 RSpliet: pecisk: yeah... I always make sure I get a .0.fc2x kernel from koji, because that's usually when they disable debugging
15:55 RSpliet: erm... but for rawhide (fc23) they usually keep it on
15:56 karolherbst: wild guess: decompress the xz module
15:56 karolherbst: I also had strange issues with it :p
15:56 RSpliet: karolherbst: no
15:57 karolherbst: yeah I think mine was signing related anyway
15:57 pecisk: well, it also said something about format error
15:57 RSpliet: Fedora kernel packaging overly complex imho, I always grab a kernel source that doesn't have debugging, hack up the specfile to become a normal release instead of a pre-release, make sure I tar up my own kernel sources and roll...
15:57 pecisk: as I tried to force it
15:57 RSpliet: pecisk: still have the bootlog?
15:58 pecisk: rebooted already sorry
15:58 RSpliet: systemd stores them
15:58 karolherbst: journalctl --boot -1
15:59 RSpliet: as root
15:59 karolherbst: and if it was the boot before the boot before your current boot, then -2 ;)
15:59 karolherbst: ohh on fedora it does matter?
15:59 RSpliet: on my machine it doesn't include the kernel log otherwise
15:59 RSpliet: silly, but true
15:59 karolherbst: I guess dmesg works as non root?
15:59 RSpliet: yes
15:59 karolherbst: ....
15:59 RSpliet: hence the "silly" bit
16:00 karolherbst: well the last boot might be "more" interessting than the current one, who knows
16:00 pecisk: bb
16:00 pecisk: last reboot
16:02 karolherbst: famous last words
16:04 karolherbst: pecisk: any progress?
16:04 pecisk: I get this modprobe: ERROR: could not insert 'nouveau': Exec format error
16:04 pecisk: nouveau: version magic '4.2.0-300.fc23.x86_64+debug SMP mod_unload ' should be '4.2.0-300.fc23.x86_64 SMP mod_unload '
16:04 pecisk: in dmsg
16:05 karolherbst: this is somehow odd
16:06 RSpliet: yes, that definitely has something to do with your kernel compile
16:07 karolherbst: RSpliet: sounds like this issue? http://forums.fedoraforum.org/showthread.php?t=305223
16:07 RSpliet: sounds legit
16:08 pecisk: heh, modprobe --verbose shows it still tries to use extra one
16:08 RSpliet: unfortunately the solution is only applicable for rpmbuild
16:08 RSpliet: which is not what we're doing
16:10 karolherbst: pecisk: when you build nouveau, what directory does make use?
16:10 karolherbst: for the -C argument
16:11 RSpliet: darktama: you're a Red Hat guy, help the poor man out a little :-P
16:11 karolherbst: :D
16:11 RSpliet: eh oh...
16:11 RSpliet: not here
16:11 RSpliet: that's a first
16:11 pecisk: karolherbst: it asked for directory without +debug, so I created symlink
16:11 imirkin: moral of the story: build your own kernels, don't use any of the fancy "protection" bs
16:12 RSpliet: bet he got tied up in a netspliet
16:12 karolherbst: pecisk: ?
16:12 RSpliet: pecisk: ah so you *do* have a debug kernel installed
16:12 karolherbst: :D
16:12 karolherbst: symlinking kernel directories is a "bad" idea
16:12 karolherbst: because name matters
16:12 pecisk: RSpliet: or was it vice versa
16:12 pecisk: one sec I will check
16:13 RSpliet: rpm -q | grep kernel
16:13 RSpliet: and uname -r
16:13 karolherbst: pecisk: uname -r is used to check which kernel is running
16:13 RSpliet: will tell you all you need to know
16:13 karolherbst: and then the directory with a matching name is used
16:13 pecisk: uname -r 4.2.0-300.fc23.x86_64
16:13 RSpliet: (do that on fpaste or hastebin or w/e please)
16:14 pecisk: http://ur1.ca/nrxk4
16:14 pecisk: in /usr/src/kernels I have +debug directory, however both kernel and kernel-headers are regular ones
16:14 RSpliet: right
16:15 karolherbst: pecisk: /usr/src/kernels should not matter
16:15 pecisk: when building it asked for normal directory, without +debug, so I symlinked
16:15 RSpliet: so what you did is link your debug-devel to a normal devel
16:15 RSpliet: so get rid of kernel-debug-devel-4.2.0-300.fc23.x86_64 and instead have kernel-devel-4.2.0-300.fc23.x86_64
16:15 RSpliet: because that's the source of all your problems
16:16 RSpliet: oh, and between the getting rid phase and the installing the right package phase, make sure you remove your symlink as well
16:16 pecisk: done
16:16 karolherbst: I am so happy I did that fN adjustment thing
16:17 RSpliet: now re-do the whole dance: recompile nouveau, install, move, strip, xz, dracut etc. etc
16:17 karolherbst: otherwise I wouldn't possibly think about the possibility, that the wrong moudle was loaded :O
16:18 RSpliet: imirkin: it's just versionmagic, and I'm glad it got in the way in a non-sensical set-up like this :-P
16:18 pecisk: hey, what do you know, proper directory appeared
16:18 imirkin: RSpliet: 99% of the time it just creates annoyances
16:18 marcosps: hi guys, good night :)
16:18 RSpliet: imirkin: it hasn't gotten in my way yet
16:19 karolherbst: a real linux user compiles its own kernel
16:19 karolherbst: :p
16:19 RSpliet: karolherbst: I roll my own kernel RPMs and do this exact thing when I want to do intermediate dev
16:19 pecisk: karolherbst: if he doesn't try to do some home cleaning sure :p
16:19 karolherbst: reading the comments of all these fancy configs is the most fun part you can ever have
16:20 imirkin: pecisk: a real linux user doesn't do any home cleaning
16:20 pecisk: imirkin: say that to my girlfriend :D
16:20 karolherbst: :D
16:20 RSpliet: the problem is pebkac really... whether you have a vanilla kernel tree or a fedora devel set-up, you *must* match your build against the right headers
16:20 pecisk: heh, there were times when I rolled out my own kernels...now I am old and bitter and fight trolls on Internet
16:20 RSpliet: pecisk: if you don't have the stones to say that yourself... :-P
16:20 imirkin: RSpliet: not really
16:20 imirkin: RSpliet: the headers just have to be close enough
16:21 karolherbst: but basically linux is _the_ showcase project for failing its initial goal so hard, no other project did before
16:21 karolherbst: so the users are allowed to do the same
16:21 RSpliet: imirkin: well, I guess you just like things the Max Power way...
16:27 pecisk: bb
16:28 imirkin: RSpliet: always!
16:28 karolherbst: RSpliet: what do you mean by "max power"?
16:30 pecisk: ok, now it is definitely proper driver, because it's in both places
16:31 karolherbst: pecisk: switch to 0f and tell me the memory clock
16:31 karolherbst: then we now for sure :p
16:31 pecisk: AC: core 405 MHz memory 6007 MHz
16:31 pecisk: seems legit
16:31 pecisk: 6008 was on table
16:32 karolherbst: okay
16:32 karolherbst: nice
16:32 karolherbst: you should be able to switch between 07/0a/0f freely without issues now
16:32 karolherbst: 0e should also work, but if not, then there might be something odd
16:32 pecisk: karolherbst: confirmed, 0a <-> 0f works
16:33 karolherbst: wuhu
16:33 pecisk: 0e works too
16:33 karolherbst: :)
16:33 pecisk: wow
16:33 pecisk: 0e gives me full package
16:33 karolherbst: imirkin: his vbios is a bit odd though, 07/0a uses 2.5 pcie and 0e/0f use 8.0
16:33 karolherbst: pecisk: "full package"?
16:34 pecisk: 966Mhz/6007Mhz
16:34 karolherbst: :D
16:34 karolherbst: ohhh well
16:34 pecisk: I will try to do some stress tests tomorrow, but so far it is peachy
16:34 karolherbst: but this is still not high enough
16:35 karolherbst: you should get 1228
16:35 karolherbst: 966 is 0a
16:35 karolherbst: there is something odd with the voltage calculation though
16:35 pecisk: yeah, I see bunch of voltage errors in dmesg
16:35 karolherbst: but I have no clue how that works, so I pass this taks to somebody with more knowledge than I have in this domain
16:37 pecisk: there is someone with more knowledge about it? :)
16:37 karolherbst: always
16:39 karolherbst: I tried myself to figure that out, but my card is strange and the blob doesn't like me
16:40 pecisk: btw, these modes are from vbios?
16:40 karolherbst: yeah
16:41 imirkin: karolherbst: why is that odd?
16:41 karolherbst: why isn't 5.0 used?
16:41 imirkin: why would it be
16:42 karolherbst: 0a is pretty fast
16:42 imirkin: tbh i don't see a great use-case for 5.0GT/s in the presence of PCIe 3.0
16:42 imirkin: either you want to save power, or you want fast
16:42 karolherbst: yeah okay, but then 0a could get 8.0 too
16:42 imirkin: what's 5GT/s good for
16:43 imirkin: PCIe speed only matters if vram is fast
16:43 karolherbst: I really have no clue, but my vbios states 07:2.5, 0a:5.0, 0f:8.0
16:43 marcosps: imirkin: http://pastebin.com/x6HyV9u0 trying to make the recursive calls work :)
16:43 pecisk: karolherbst: also last question - to make good use of reclocking driver will have to use some intelligence to switch between them?
16:43 marcosps: imirkin: until now I know that a Insn can have a ValueRef, and this value can have another Insn, and go on...
16:43 karolherbst: pecisk: well this isn't the problem
16:44 imirkin: marcosps: you need to call getImmediate for all the sources of the merge
16:44 imirkin: and then manually merge them into one big immediate
16:44 imirkin: marcosps: it's fine if you just limit it to 64-bit merges though... there's never any support for anything higher
16:44 marcosps: imirkin: and this is the insnCanLoad part: http://pastebin.com/x9pMjnbg
16:45 karolherbst: pecisk: it should be stable first, then the intelligence is already there
16:45 pecisk: sure :)
16:45 marcosps: imirkin: Hum... I'll try to check the type of the value to filter, if you say this is easier for now :)
16:45 karolherbst: pecisk: what's the output bout the voltage stuff?
16:45 glennk: imirkin, pcie link speed mostly matters if you have a prime setup
16:46 karolherbst: just an error or anything usefull?
16:46 pecisk: karolherbst: same error as before
16:46 pecisk: [ 200.339655] nouveau 0000:01:00.0: clk: failed to raise voltage: -22
16:46 pecisk: [ 200.339658] nouveau 0000:01:00.0: clk: error setting pstate 3: -22
16:46 karolherbst: pecisk: reboot with nouveau.debug=debug
16:46 karolherbst: and then give the demsg output after changing to 0e/0f
16:46 karolherbst: would like to know what exactly is failing
16:47 pecisk: roger
16:47 pecisk: bb
16:48 karolherbst: mhhh
16:48 karolherbst: could nouveau be upset bout 1.25V voltage?
16:53 pecisk: http://ur1.ca/nrxwh
16:53 pecisk: karolherbst: ^^
16:54 karolherbst: pecisk: I need more
16:54 karolherbst: also nouveau loading time and stuff
16:54 karolherbst: sudo ournalctl --boot 0 | grep nouveau
16:54 karolherbst: ..
16:54 karolherbst: sudo journalctl --boot 0 | grep nouveau
16:56 pecisk: karolherbst: all of it http://fpaste.org/266749/42188563/
16:57 karolherbst: mhhh
16:58 karolherbst: okay
16:58 karolherbst: as I thought
16:58 karolherbst: there is somehwere an index issue
16:59 karolherbst: okay, we can try something
17:00 karolherbst: pecisk: please switch to my karlton_test branch
17:00 karolherbst: and compile nouveau from there and install it
17:01 karolherbst: mupuf_: it seems like the wrong voltage map entry is getting used, which messes up 0f pstates quite frequently when the "highest" voltage entry + 1 has bad voltage info
17:01 karolherbst: usually the entry +1 is used
17:02 karolherbst: pecisk: what happens when you switch back to 07
17:02 karolherbst: does the core clock changes?
17:03 karolherbst: or do you also get such an voltage issue?
17:03 karolherbst: you could switch to 0a before to check that
17:03 pecisk: karolherbst: yes, it switches back to 405
17:03 karolherbst: mhhh
17:03 pecisk: when I switch to 07
17:04 karolherbst: but I saw this issue with my card too, so maybe I will be able to debug that myself
17:04 pecisk: karolherbst: what's interesting though that if I switch to 0e directly, I get 405, but if I switch to 0a and then to 0e, I get 966
17:04 karolherbst: yeah
17:04 karolherbst: thats because of the voltage
17:04 karolherbst: 966 is used for 0a
17:05 karolherbst: and 0e should have 1226, but because changing voltage fails, it stuck with 966
17:05 karolherbst: so to get higher perf, you need to switch to 0a before switching to 0e/0f
17:05 karolherbst: I think I will figure the issue out by tomorrow
17:05 karolherbst: but who knows what the cause is
17:06 karolherbst: skeggsb: any new comments on my gddr5 patch? https://github.com/karolherbst/nouveau/commit/173f1d7e09af8abce576e2c09190032c5e90bfd4
17:06 karolherbst: it seems to work for quite a lot people
17:07 karolherbst: if we just ignore all the other reclocking issues
17:08 skeggsb: karolherbst: will likely push it at some point, but i hope to be able to talk to nvidia directly about that particular issue in the near future too, so been holding off to hear what comes of that
17:08 karolherbst: yeah no worries
17:08 karolherbst: I just wanted to know if the design of that patch is fine
17:08 karolherbst: if there is something not good enough or bad designed, I would like to know that :D
17:09 karolherbst: because of testing and such
17:09 skeggsb: if that's what actually needs to be done, then yes, the patch is fine :) i'm not (yet) convinced there's not a more direct calculation we should use though, but, it's entirely possible i'm wrong :P
17:09 karolherbst: yeah I know
17:09 karolherbst: I didn't tried to be smart there so I stick with something simple
17:09 pecisk: karolherbst: I have to catch some sleep here too, but I can test tomorrow again...I will be around
17:09 karolherbst: k
17:10 skeggsb: yeah indeed, and if we don't get something helpful from nv, i'll push it for sure
17:10 skeggsb: as it's better than now
17:10 karolherbst: skeggsb: I was thinking about precalculating those for the psatets at loading time though
17:10 karolherbst: because the memory clock is kind of "stable"
17:10 karolherbst: so no need to calculate these several times
17:10 skeggsb: given how long a memory clock change takes, i'm not sure you gain much from saving that tiny amount of time
17:10 karolherbst: :D
17:10 karolherbst: right
17:11 karolherbst: but there aren't that many calculations anyway
17:11 karolherbst: 72 checks max I think
17:11 karolherbst: ohh right
17:11 imirkin: skeggsb: btw, i pushed the glamor removal changes
17:12 karolherbst: skeggsb: there is also the possibility of having the P argument set to 2, but somehow I didn't care enough for implementing it
17:12 karolherbst: how hard do you fell about it?
17:12 pecisk: see ya guys, good luck
17:12 skeggsb: imirkin: nice
17:12 imirkin: [along with a build fail, which i promptly fixed up]
17:12 skeggsb: karolherbst: well, nvidia definitely use it, could be important :P
17:13 karolherbst: with the fN adjustment I get 0.002 Mhz close to the requested one
17:13 karolherbst: mhhh yeah I know
17:13 karolherbst: but the blob isn't as perfect as this patch near the clock
17:13 karolherbst: usually there is a range of 6MHz around the requested one
17:14 skeggsb: yeah, there might be other reasons why they choose that though
17:14 karolherbst: maybe
17:14 skeggsb: (more stable, or whatever)
17:14 karolherbst: ...
17:14 karolherbst: hopefully
17:15 karolherbst: sad that this information doesn't seem to be in the bios
17:15 karolherbst: or I didn't look hard enough
17:15 skeggsb: yeah, that is a bit interesting, or we possibly misunderstand how it's supposed to be used
17:15 skeggsb: *shrug*
17:15 skeggsb: we'll find out eventually, with enough data
17:16 karolherbst: ohh I am pretty sure I figured at least this PLL part out pretty perfectly. luckily the blob allows to adjust the memory clock, so I could try out a lot of clocks
17:17 karolherbst: and see how the PLLs are getting changed
17:17 karolherbst: there might be combinations where N might be 0x24 or 0x2c for the refclock though, but I didn't see any
17:19 karolherbst: also besides the fN value, my algorithm chooses the same PLL configuration as the blob does
17:19 karolherbst: without actually optimizing it for this
17:19 skeggsb: that's generally a good sign :)
17:19 karolherbst: thought the same
17:20 karolherbst: you remember my table I create for this?
17:25 marcosps: imirkin: I noticed right now: in insnCanLoad, I'm using ld to call getImmediate and test the op. Should I use "i" in this case, since I call i->setSrc(1, newImmediate()) ?
17:26 imirkin: marcosps: "test the op"?
17:26 imirkin: marcosps: i can't tell whether you're understanding what the various variables are...
17:26 imirkin: i = the instruction that's potentially going to load some arg DIRECTLY
17:27 imirkin: ld = the instruction that loads that value into a register
17:27 imirkin: in order to tell whether the op can perform the load, it has to know what's being loaded
17:28 marcosps: imirkin: Sometimes I got confused about the i->getSrc(x)->getInsn()->getSrc(y)...
17:28 karolherbst: skeggsb: there is a possibility to do a by 0 division in my code :/
17:28 imirkin: marcosps: yeah, it's best to avoid such long chains
17:28 karolherbst: for clocks like 40 MHz
17:29 imirkin: marcosps: and create intermediate variables that explain what's going on
17:29 marcosps: imirkin: I beleive I'm misunderstanding the problem itself...
17:29 imirkin: marcosps: potentially even with, *gasp*, comments
17:29 imirkin: ok
17:29 imirkin: so here's the situation
17:29 imirkin: there are instructions
17:29 imirkin: they have destinations, and they have sources
17:29 imirkin: so far so good?
17:30 imirkin: [if i've already lost you, that's a bad sign]
17:30 marcosps: imirkin: Yes, this instruction can have an operation, such as load or merge, and this operations have source variables/values, and destinations variables/values...
17:30 marcosps: imirkin: I'm on the right track...? :)
17:30 imirkin: let's not worry about specific instruction names
17:30 imirkin: so at the end of the day, these instructions have to be written out in a way that the hardware can execute
17:31 imirkin: and while in our IR (intermediate representation) we can express all sorts of things
17:31 imirkin: there's no guarantee that the hardware can actually understand all that
17:31 imirkin: so if for example you have x = add(1, 2)
17:31 imirkin: [and you weren't doing constant folding]
17:32 imirkin: you might be tempted to create an instruction with the first src as the immediate 1, and the second src as the immediate 2
17:32 imirkin: the nv50 ir is perfectly capable of representing this
17:32 imirkin: HOWEVER
17:32 imirkin: the hardware just doesn't have a way of doing that
17:32 imirkin: an immediate can only be in the second argument, never the first
17:32 imirkin: so it has to become like
17:32 imirkin: reg = load immediate 1
17:32 imirkin: x = add(reg, 2)
17:33 imirkin: does that make sense?
17:33 marcosps: imirkin: yes
17:33 imirkin: ok
17:33 imirkin: so in order to do this in a generic way
17:33 imirkin: we put *everything* through a mov first
17:33 imirkin: and then try to propagate the value directly into the instruction if the target allows this
17:33 imirkin: so we call targ->insnCanLoad() which tells us whether a particular insn can load a particular value into a particular source slot
17:34 imirkin: makes sense?
17:34 marcosps: imirkin: yes, it's more clear now.
17:34 imirkin: so normally you have a sequence like
17:34 imirkin: mov a, 2;
17:34 imirkin: mov b, 1;
17:35 imirkin: add c, a, b
17:35 imirkin: (in intel-style notation... i.e. dest first)
17:35 imirkin: so when we hit the add op
17:35 imirkin: we see - aha, it has 2 args
17:35 imirkin: what are the sources of each of those
17:35 imirkin: if it's a load (like a mov)
17:36 imirkin: then we try to see if the target can actually load that value *directly*
17:36 imirkin: which will be the case... sometimes
17:36 imirkin: for abelian ops (sorry, blanking on the common name for this), we also try swapping the two args
17:37 imirkin: so that if you have like 1 + a, it'll swap it into a + 1 which can work
17:37 imirkin: er actually abelian has nothing to do with it. ignore that comment.
17:38 marcosps:is understanding about that function that swap things...
17:39 marcosps: imirkin: Your explanation clarified a lot of doubts I had.
17:39 imirkin: cool
17:40 imirkin: it's a greedy approach, so we don't always end up doing the *best* thing in that situation but... meh
17:40 marcosps: imirkin: The last one is: how do I know what srcs do I need to check in each op? I need to check each op and then look to its parameters? Like the OP_MERGE, I need to check for src(0) and src(1)?
17:41 imirkin: so you're extending the rules a bit
17:41 imirkin: now you're saying not only if the target op is a load, but also if it's a merge (and it's a 64-bit op)
17:41 imirkin: so you have to ensure that the merge is of 2 constants
17:41 imirkin: er, immediates
17:42 karolherbst: mhhh
17:42 karolherbst: the blob actually let me set the memory clock to 14GHz
17:42 karolherbst: ...
17:42 marcosps: imirkin: Hum... ok. This is what I'm doing in insnCanLoad. The challange for me now is how to adapt the getImmediate to reflect this behavior.
17:43 imirkin: right
17:44 marcosps: imirkin: Right now, I'm calling getImmediate with src(0) and src(1) of ld, when the op is OP_MERGE
17:44 marcosps: (after check dType and sType)
17:44 imirkin: but ld is really the merge
17:44 imirkin: so... not ld :)
17:44 imirkin: right, and if both of the sources are immediate
17:44 imirkin: then you just | them together
17:45 imirkin: and return true after setting the ImmediateValue to the merged thing
17:45 imirkin: nice and simple
17:45 marcosps: hum...
17:46 marcosps: imirkin: I understood this is theory hehe
17:46 marcosps: imirkin: I'm jsut thinking about how to do it in getImmediate...
17:46 imirkin: but anyways, to be clear i haven't *fully* thought through all the implications
17:46 imirkin: so if you have better ideas, by all means, implement it that way
17:46 imirkin: the idea here is that you're implementing this, not me
17:46 imirkin: :p
17:46 marcosps: imirkin: right now I'm checking src->getInsn() and then check for src(0) in getImmediate...
17:47 marcosps: imirkin: Ok, I get it, the problem is in my hands :)
17:48 marcosps: imirkin: Just a last question: you said "but ld is really the merge. So... not ld"
17:48 imirkin: well, the variable name might be 'ld'
17:48 marcosps: imirkin: so, calling ld->src.getImmediate(0) is wrong in this case...?
17:48 imirkin: but just coz it's written... doesn't make it so ;)
17:49 imirkin: no, it's not wrong
17:49 imirkin: in fact i think it's right.
17:49 imirkin: except not (0)
17:49 imirkin: but for each source
17:49 marcosps: sorry: ld->src(0).getImmediate(imm)
17:50 imirkin: right, so you need to do that both for src(0) and src(1)
17:50 marcosps: imirkin: yes. SO, it seems my last problem (in this part of the code...) is inside getImmediate :)
17:51 imirkin: yeah, right... last problem. famous last words!
17:51 marcosps: (last problem until the next onde... :P )
17:51 marcosps: *one
17:52 marcosps: imirkin: I'll not bother you anymore. Next attempt to fix it! Thanks :)
17:56 karolherbst: skeggsb: when do you expect an answer from nvidia? :D
17:56 karolherbst: skeggsb: anyway, I did test some values against the blob and I would say in 25% of the cases I hit the same values
17:56 imirkin: i've long given up on getting any answers...
17:56 karolherbst: usually, when the fN=0x0
17:57 karolherbst: but there are other cases as well
17:57 karolherbst: imirkin: ohh mhh
17:58 orospakr: hey, silly question here: the optimus support logic in nouveau and the switcheroo framework is about using the mux, but PRIME is doing the indirect rendering on another GPU to a texture on another, yes?
17:58 skeggsb: karolherbst: i'll merge a fix one way or the other (quite likely your patch lol) for the next merge window
17:58 karolherbst: :)
17:58 karolherbst: okay
17:58 karolherbst: will target pcie speed for 4.5 if that's fine by you then
17:59 airlied: orospakr: not totally, the optimus support logic is used to power up/down the secondarfy gpu
17:59 karolherbst: want to test that on my fermi card too and don't want to get it mixed with the gddr5 stuff
17:59 karolherbst: :D
17:59 airlied: even if there is no mux
17:59 karolherbst: airlied: what I was thinking about, do you know how the gpu data is transfered on windows for example?
18:00 airlied: karolherbst: same way we do it, blit it to somewhere the igpu can show it
18:00 karolherbst: okay
18:00 karolherbst: so there is no technically difference anyway
18:00 orospakr: airlied, aha, that explains my next question, then. because I'm on an effectively muxless system (rMBP 10,1 with the EFI setting that switches the mux to the intel), it seems that runtime power management (dynpwr) is disabled.
18:00 karolherbst: only some software problems, but that should be fine
18:01 karolherbst: skeggsb: if you want to see the P=2 part as well, I can fix that up too, shouldn't be too difficult
18:02 orospakr: although, oddly, I can write "OFF" to switcheroo/switch and apparently get nouveau to suspend, although the laptop seems to remain hot (and things get unstable because it seems that the HDMI audio device isn't properly disabled)
18:02 airlied: orospakr: yeah apple isn't optimus
18:03 airlied: they have their own system for doing things using apple-gmux
18:03 orospakr: my audio systems make sense, because looking at the noveau code that binds to switcheroo, seems like disabling HDMI audio is done as a side-effect of suspending the display hardware at a fairly low level
18:04 orospakr: s/systems/symptoms/
18:04 orospakr: right, fair enough.
18:06 airlied: therre are some patches on dri-devel that move things towards turning the power off
18:07 orospakr: upon closer inspection, it looks like when nouveau registers itself as a client with switcheroo, it specifies whether it supports dynamic power management as a function of having optimus or the older DSM. I think that's my trouble.
18:09 orospakr: although I think that the gmux support for powering off the silicon isn't actually functional on this rev of the hardware in the first place, though. i'll definitely have a look for those patches, thanks :)
18:16 orospakr: airlied, is it Lukas Wunner's patch? http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html
18:17 airlied: orospakr: yeah a whole series of them
20:35 imirkin: could i trouble someone for a 'glxinfo -l -s' on mesa 11.0 (not git) and a g80:g98 gpu?
20:41 marcosps: imirkin: can this be done by a nvc0 board?
20:41 imirkin: can what be done?
20:42 marcosps: imirkin: the glxinfo command :P
20:42 marcosps: imirkin: you asked for help...
20:42 imirkin: sure. but it won't provide the results i want.
20:42 marcosps: imirkin: ok...
20:42 imirkin: this is for my page at http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
20:44 marcosps: imirkin: nice :)
20:44 imirkin: so it needs to be against the G80:G98 class of gpu's
20:45 imirkin: in order to provide the relevant information
20:45 imirkin: (i.e. the DX10 gpu's)
20:46 marcosps: imirkin: got it :)
20:53 marcosps: imirkin: http://pastebin.com/R6GQ90BU in getImmediate I can reach two sources when insnCanLoad call getImmediate with ld->src(0). This is right...? I believe in this case we need the recursion you said...
20:54 imirkin: why are you checking if the merge's *sources* are f64?
20:54 marcosps: T.T
20:55 imirkin: Instruction *insn = src->value->getUniqueInsn();
20:55 imirkin: you need to place your code below that line
20:55 imirkin: if (insn && insn->op == OP_MOV) {
20:55 imirkin: you need to have a thing that's like
20:55 imirkin: if (insn && insn->op == OP_MERGE) { ... }
20:55 marcosps: hum...
20:55 imirkin: which calls getImmediate on each of the merge's sources
20:56 imirkin: and if they're both immediates
20:56 imirkin: then combine the results and return true
20:57 marcosps: so, the magic is in getUniqueInsn...
20:57 imirkin: not really magic
20:57 imirkin: it's the same as getInsn()
20:57 imirkin: except it checks that it's the only defining instruction
20:58 imirkin: and asserts otherwise
20:58 imirkin: (iirc)
21:00 marcosps: imirkin: when you say combine, it's because they are 32bit each? I thought it'll be only one, but a 64bit one, because we set it in LoadPropagation...
21:01 imirkin: merge takes 2 sources
21:01 imirkin: each source is 32-bit
21:02 imirkin: the merge combines them into 1 64-bit value
21:02 imirkin: LoadPropagation is where you need the check in the first place
21:26 marcosps: imirkin: I'm still having problem here heheheh
21:26 marcosps: imirkin: maybe it's because it's almost 1:30 AM here... I'm going to sleep. Thanks for all the hep tday!
23:08 Boohbah: hi, my GTX 275 fan goes to full speed resuming from suspend in 4.3-rc1
23:09 imirkin: did this not happen with 4.2/earlier?
23:12 Boohbah: imirkin: correct, it does not happen in 4.2 or earlier
23:15 imirkin: Boohbah: nouveau got a substantial refactor in 4.3... it should be bisectable, could you figure out which commit broke it?
23:15 Boohbah: okay, i will try to do a bisect
23:17 imirkin: Boohbah: btw, 4.3-rc1 should support reclocking for the NVA0, so you should be able to get a bit more perf out of it if you boot with nouveau.pstate=1 and futz with the pstate file
23:18 Boohbah: i have used the nouveau.pstate=1 for a while, but i don't know about the pstate file
23:19 imirkin: it's /sys/class/drm/card0/device/pstate
23:19 imirkin: starting with 4.3-rc1 you can echo things into it in order to change the perf state
23:20 Boohbah: ah, cat'ing it gives me a list of frequencies
23:20 imirkin: and you can echo the relevant levels to it
23:20 imirkin: in order to switch to the level
23:21 imirkin: e.g. i have "0f: core 710 MHz memory 500 MHz", so i can echo "0f" into the file to switch to that state
23:21 imirkin: (well, not really, coz reclocking doesn't work on my card, but you get the idea)
23:21 Boohbah: i will try to quiet my fan with the pstate file, first
23:21 Boohbah: thank you
23:22 imirkin: futzing with pstate is unlikely to affect the fan situation
23:22 imirkin: you can look at the pwm hwmon thing
23:22 imirkin: look in /sys/class/drm/card0/device/
23:22 imirkin: but it should be auto-set based on the temperature
23:22 imirkin: perhaps we flip it into manual mode by accident on resume now or something
23:47 Boohbah: imirkin: /sys/class/drm/card0/device/hwmon/hwmon0/power/control is set to auto before and after suspend
23:48 imirkin: that's the wrong thing
23:48 imirkin: you want pwm1_enable
23:48 imirkin: it should read '2'
23:50 Boohbah: i don't find any file named pwm* under the device directory
23:50 Boohbah: i see the wiki says "I²C fans cannot be managed with Nouveau's hwmon interface."
23:51 imirkin: what do you see in there?
23:51 imirkin: it wouldn't be in the 'power' dir
23:51 imirkin: it'd be in 'hwmon0'
23:51 imirkin: or hwmon1/etc
23:52 imirkin: perhaps you're just looking at the temp probe
23:54 Boohbah: http://ix.io/kNp
23:54 imirkin: is there an hwmon1/2/3?
23:54 Boohbah: that is the only hwmon
23:54 Boohbah: i do have a few i2c dires under device
23:54 imirkin: hm ok
23:55 imirkin: well, doing a bisect should finger the commit that killed it
23:56 Boohbah: i will get to bisecting
23:56 Boohbah: thank you for your help