01:04 karolherbst: mupuf: okay, false alarm about the maxwell card. The memory doesn't get reclock at all and I somehow assume, that the card crashes due to wrong voltage being set or none at all, because I hadn't your patches in my tree ;)
01:07 slacka123: In the past when I wanted to test mesa git, I'd just build it and test it by setting LD_LIBRARY_PATH. But now you require libdrm 2.4.61. Even Ubuntu 15.10 is still on 2.4.60. So now I'm in distro breaking territory. Any Ubuntu users here have any tips?
01:10 karolherbst: slacka123: xedgers ppa?
01:10 karolherbst: slacka123: https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa
01:10 karolherbst: this ppa already uses pretty new version of all those libraries
01:12 karolherbst: slacka123: also read the notice there ;)
01:14 slacka123: karolherbst: Good idea. I didn't think of using a PPA. thanks. Is that what you're doing?
01:15 karolherbst: I don't use ubuntu on the laptop I usually use, but here is another one, where this PPA is getting used
01:15 karolherbst: and there was no problem with that so far
01:15 karolherbst: if you understand what the notice says, then you should be fine
01:15 karolherbst: anyway, it's easier to just use that PPA instead of managing a local git tree ;)+#
01:21 pecisk: karolherbst: hey
01:23 slacka123: karolherbst: OK thanks again
01:24 karolherbst: pecisk: hi
01:32 pecisk: karolherbst: I can try to poke my laptop now and then
01:43 karolherbst: pecisk: ohh okay, it had a maxwell card, didn't it?
01:43 karolherbst: if you want you could try to load the nouveau module by hand inside X, but I somehow think the server will crash :D
01:43 pecisk: 850M, GM107M
01:43 pecisk: yeaaah, I think it will
01:43 karolherbst: but this is a X server bug
01:44 karolherbst: pecisk: is the nouveau xserver driver installed?
01:44 pecisk: one sec
01:44 karolherbst: I think you won't need it with x server 1.17 or 1.16 anymore, because there is the modesetting driver
01:50 pecisk: karolherbst: there is xorg nouveau driver
02:01 karolherbst: pecisk: I would remove it, because you won't need it anyway
02:02 karolherbst: maybe this will stop the X server doing crazy things
02:23 karolherbst: pecisk: you could try then do load the nouveau kernel module after removing the xorg nouveau driver, the server may or may not crash, but it shouldn't use the nouveau card right away
02:38 pmoreau: Cool! The first XDC videos are already uploaded!!
02:52 rigid: hi
02:53 rigid: i'm still struggling with a bug that segfaults glxinfo, blender and mplayer. And I have no idea how to investigate it. That's the backtrace: https://gist.github.com/609295816b01495dc08d
02:54 rigid: that's my dmesg: https://gist.github.com/609295816b01495dc08d
02:55 rigid: oh sorry, i mean that: https://bpaste.net/show/76dbb3dc6d7c
02:55 rigid: and that's my Xorg.log: https://bpaste.net/show/06e53202f6a3
02:56 rigid: any slight hint would be highly appreciated
03:00 karolherbst: rigid: I think some of your libraries are just borked
03:01 karolherbst: rigid: did you compile anything yourself?
03:01 rigid: karolherbst: yes, everything. I'm running gentoo :)
03:01 karolherbst: I see
03:01 karolherbst: mhh
03:01 karolherbst: you could run revdep-rebuild
03:01 rigid: not only that, I'm using clang. If I only knew what, I could select it to compile with gcc
03:01 karolherbst: but this shouldn't catch those errors
03:01 karolherbst: ohh clang
03:02 karolherbst: so you will help catching bugs? nice :p
03:02 rigid: karolherbst: revdep-rebuild has been replaced by emerge @preserved-rebuild ... But I could still try, it should be fine though
03:02 karolherbst: I would add expat
03:02 rigid: sure, if I can help... i'm just not very able to find it, but I can by the typing monkey :)
03:02 karolherbst: rigid: revdep-rebuild does something different though
03:03 karolherbst: and not every package adds its slot dependency
03:03 rigid: expat? to what?
03:03 karolherbst: I am not sure, but I always thought revdep-rebuild also checks for symbol errors
03:03 karolherbst: to build it with gcc
03:03 rigid: yes, running right now
03:04 karolherbst: though the issue may be somewhere else
03:04 karolherbst: rigid: do you have a debug env file?
03:04 rigid: no, but I can create one
03:04 karolherbst: rigid: https://gist.github.com/karolherbst/14b01cdb2af83eb2cc22
03:06 rigid: ok, what should I compile with debug flags?
03:06 karolherbst: expat if building with gcc doesn't help
03:06 karolherbst: and mesa
03:06 karolherbst: and mesa-progs
03:06 rigid: you think the crash comes from expat? because GL stuff doesn't crash in expat but in other libs (libpulse for example) ... sec
03:07 karolherbst: well, nobody really tests with clang, so
03:08 rigid: not? clang is so cool :)
03:08 rigid: here is my mplayer vdpau crash backtrace: https://gist.github.com/anonymous/a69131ae98a8d0470014
03:09 karolherbst: ui "Illegal instruction."
03:09 karolherbst: that sounds bad
03:09 karolherbst: didn't I noticed anything? wait
03:09 rigid: oh, blender also crashes in expat
03:09 rigid: i'll recompile expat with gcc
03:09 karolherbst: the illegal instructions is messy
03:09 karolherbst: what are your CFLAGS?
03:09 karolherbst: and what is your cpu
03:10 rigid: revdep-rebuild found nothing
03:11 rigid: /proc/cpuinfo: https://bpaste.net/show/b5728472f7c2
03:11 karolherbst: rigid: in mplayer gdb
03:11 karolherbst: do "layout asm" when you got the SIGILL
03:11 rigid: CFLAGS="${CFLAGS} -O2 -march=native -fomit-frame-pointer -fno-stack-protector -pipe"
03:12 karolherbst: and "display/i $pc" in gdb too
03:13 rigid: and paste the output?
03:13 karolherbst: yeah
03:13 karolherbst: I want to know whcih instruction it tries ti execute
03:13 rigid: https://gist.github.com/anonymous/130b7e8f315547f6f3e8
03:13 karolherbst: chances are, that march=native has a bug
03:14 karolherbst: oh well :/
03:14 karolherbst: display/i 0x7fffed7d036f
03:15 rigid: 0x7fffed7d036f: add %cl,(%rsi)
03:15 karolherbst: mhh
03:15 karolherbst: yeah, something is wrong in the binary
03:15 rigid: why 36f when the bad instruction is at 370 ? hm... i suppose you know what you're doing :D
03:16 rigid: i just recompiled it with gcc
03:16 karolherbst: 370 is part of the instruction in 36f
03:16 rigid: ah ok
03:16 karolherbst: most instructions aren't just one byte big
03:16 rigid: i see
03:17 karolherbst: so the program just jumped to something bad
03:17 karolherbst: could be the compilers fault
03:17 rigid: hm, or maybe my HDDs fault?
03:17 rigid: i could recompile everything to rule that out
03:18 karolherbst: rigid: anyway, it's not a nouveau bug, but rather a clang/llvm bug or library bug, who knows
03:18 karolherbst: you should ask in the llvm IRC channel or just open some bugs for llvm
03:18 karolherbst: if you want to be safe, use gcc ;)
03:18 rigid: hm, i'd double check that... i'll recompile everything with gcc just to be sure
03:20 karolherbst: if you want to have more binary performance, you should rather stick with ICC anyway. I don't think you can use clang seriously today for your whole system except you are on *BSD or something
03:22 rigid: karolherbst: hm, yeah... i have a few packages that need gcc but otherwise i'm quite happy with llvm and LTO using the gold linker (although LTO is disabled on this machine)
03:22 rigid: karolherbst: thank you for now, I'm trying to recompile my system now... might come back in 2 days :D
03:24 karolherbst: you also get lto with gcc ;)
03:24 karolherbst: since 4.9 it's quite usable
04:10 pecisk: karolherbst: package successfully removed, will try loading module after finishing some tasks
04:16 karolherbst: okay
04:41 pecisk: karolherbst: 'modprobe nouveau' brought SCHED_ERROR in dmesg and froze system for 3 - 4 secs, but then I got back (I guess because Xorg uses i915 and it has no nouveau driver)
04:42 karolherbst: ohh okay, that's good then
04:42 karolherbst: is there something before those SCHED_ERRORs?
04:42 karolherbst: also is there anything on the Xorg log?
04:50 pecisk: http://ur1.ca/nt5l5
04:50 pecisk: I got this *after* sched_error
04:51 karolherbst: mhh okay
04:51 karolherbst: cat /sys/kernel/debug/vgaswitcheroo/switch
04:52 pecisk: also have these few lines between [14022.501689] nouveau E[ PFIFO][0000:01:00.0] runlist 0 update timeout
04:52 pecisk: [14022.502271] nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ UNK06 ]
04:52 pecisk: [14022.502799] nouveau E[ PFIFO][0000:01:00.0] FB_FLUSH_TIMEOUT
04:53 pecisk: [root@localhost peteris]# cat /sys/kernel/debug/vgaswitcheroo/switch
04:53 pecisk: 0:IGD:+:Pwr:0000:00:02.0
04:53 pecisk: 1:DIS: :DynOff:0000:01:00.0
04:55 avph: pecisk: those errors looks very similar to what I have: https://bugs.freedesktop.org/show_bug.cgi?id=90276 and https://bugs.freedesktop.org/show_bug.cgi?id=90453
04:57 pecisk: avph: yeah, it looks familiar
04:57 avph: I'm trying to bisect it because I think they do not happen v3.14...
05:00 karolherbst: pecisk: at least this card got turned off without problems
05:00 karolherbst: "problems
05:00 karolherbst: "
05:00 mupuf: karolherbst: :)
05:00 karolherbst: pecisk: you could try to reboot without blacklisting nouveau though
05:00 karolherbst: and if that doesn't cause any issues, you can forget about those SCHED_ERRORS for now, because it doesn't matter when the card is off
05:01 karolherbst: at least your laptop is in a state where this issue can be debuged
05:02 pecisk: karolherbst: there's one issue if I remember for yesterday - SCHED_ERR coming each time I opened new tty or new terminal or did su
05:02 karolherbst: mupuf: I was thinking of checking if I can do anything with my cstate patches and see if for some voltages it is stable though
05:02 karolherbst: and some clocks
05:02 karolherbst: that would be at least one thing done for maxwell recklocking then
05:03 mupuf: yeah, but if it does not work for some cstates, adds code that select a voltage in the middle of min and max for the cstate
05:04 karolherbst: mupuf: as far as I understoof the patches, you don't have any bound checks in them, do you?
05:04 mupuf: reversing the equation should be easier now that we have cards where we get such a high resolution (96 steps instead of 16)
05:04 mupuf: bound checks? which patches are you talking about?
05:04 karolherbst: the pwm patches
05:04 mupuf: oh, ... indeed.
05:05 mupuf: true, it should be checked
05:05 mupuf: care to cook a patch for that?
05:05 karolherbst: depends :D
05:05 mupuf: it should be trivial-enough :)
05:06 karolherbst: somehow I get the feeling, that pcie speed won't be done until 4.6 if that keeps up :D
05:06 mupuf: if you are outside of the range found in the voltage table's header, then return -EINVAL
05:06 mupuf: hehe, this is always like that
05:06 mupuf: but ack
05:06 mupuf: I can cook the patch today
05:06 karolherbst: at least gddr5 is done
05:06 mupuf: or tomorrow
05:06 mupuf: is it merged?
05:06 karolherbst: no, but planned for 4.4
05:06 karolherbst: skeggsb wants an answer from nvidia
05:06 mupuf: ack
05:07 karolherbst: so I think he waits until the merge window is closed for drm
05:07 karolherbst: something like that
05:07 mupuf: I need to send emails to nvidia too
05:07 mupuf: anyway, I still have no finished my presenttion for tomorrow
05:07 karolherbst: mupuf: "<skeggsb> karolherbst: i'll merge a fix one way or the other (quite likely your patch lol) for the next merge window"
05:07 mupuf: so, if you excuse me, I will work on that
05:07 karolherbst: no problems :)
05:08 mupuf: we will have the nouveau talk with gnurou in about two hours
05:08 karolherbst: I have no clue what that is :)
05:09 mupuf: what it is?
05:09 mupuf: it is just a status update for nouveau, at the xorg developer conference
05:09 mupuf: it is happening in toronto this year
05:10 karolherbst: ohh okay
05:10 mupuf: on the nouveau side, there is skeggsb, gnurou, hakzsam_, andy ritger and myself
05:10 karolherbst: I am not that into all these conferences and what exists and everyhing :)
05:10 mupuf: :)
05:10 karolherbst: also your | 0x80000000 fix is missing ;)
05:10 mupuf: the xdc is a ton of fun and we get to meet most of the people working on the graphics stack
05:10 karolherbst: ohh wait
05:10 mupuf: karolherbst: it has been pushed again yesterday
05:10 karolherbst: not its in there
05:11 karolherbst: my bad
05:11 karolherbst: yeah, saw it now
05:11 karolherbst: mupuf: yeah I can imagine, never was to such kind of conferences though
05:11 mupuf: and I sent the patch to enable the GM204/6 too
05:11 mupuf: maybe next year :)
05:11 mupuf: but hey, really need to go! See you!
05:12 karolherbst: bye
05:12 karolherbst: I need to create a branch with stable stuff I did :/
05:15 pecisk: +!
05:15 pecisk: +1
05:15 pecisk: karolherbst: so for now, there's not much I can do with laptop, right? :)
05:15 karolherbst: ohh you can, you could figure out why you get those errors :D
05:16 karolherbst: there is only one situation where you can't do anything: no issues
05:17 RSpliet: oh yes, that happens to me all the time
05:17 RSpliet: so annoyinhg
05:17 RSpliet: -h
05:18 pecisk: I could try to debug it just have little understanding what could be direction or reason. there's some ACPI messages between there
05:18 karolherbst: the ACPI message doesn't matter
05:18 karolherbst: this method is just implemented the wrong way on like all boards
05:19 karolherbst: pecisk: try DRI_PRIME=1 glxinfo :D
05:19 karolherbst: this may be messy, but well
05:19 pecisk: ok, I will save my work then :p
05:22 pecisk: karolherbst: success
05:22 pecisk: http://ur1.ca/nt5tk
05:22 karolherbst: or not
05:22 karolherbst: "OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile"
05:22 karolherbst: okay
05:22 karolherbst: then DRI2 it is
05:22 karolherbst: http://nouveau.freedesktop.org/wiki/Optimus/ follow the DRI2 instructions there
05:23 pecisk: xrandr --listproviders shows only Intel :)
05:23 karolherbst: wow, 0x13 in 0x2344
05:23 karolherbst: pecisk: most likely you need to restart X
05:24 pecisk: DDR2 setup asks for "DDX drivers for both GPUs loaded."
05:25 karolherbst: modesetting is fine
05:27 pecisk: so you suggest to remove nouveau from blacklist, restart, and then try DRI2 instructions
05:27 karolherbst: mhh well you could restart X too
05:28 karolherbst: if that works we can remove nouveau from blacklist
05:29 karolherbst: mupuf: it would be nice to have something like vgaswitcheroo on reator, so that the gpus can be turned off instead of rebooting reator
05:29 mupuf: right, but I doubt we can do that ...
05:30 karolherbst: at laest I got nouveau unloaded
05:30 karolherbst: even on lowest cstate the maxwell card crashed
05:30 karolherbst: allthough its fine on stock voltage
05:30 pecisk: bb
05:32 karolherbst: now the card crashed :/
05:44 pecisk: karolherbst: xrandr still gives me just Intel after Xorg restart, I will reboot
05:45 pecisk: karolherbst: one thing though - if nouveau module is active, every tty login, and every sudo bash give me SCHED_ERR
05:45 pecisk: so I suspect something in bash profile triggers it
05:45 karolherbst: mupuf: okay, your geerated pwm values are too low for the maxwell card. Using the middle between min and max seems to work for the lowest clock
05:46 mupuf: karolherbst: ack, not for others?
05:46 karolherbst: didn't test these yet
05:46 karolherbst: something is strange though
05:46 karolherbst: higher clocks have 1306250uv
05:46 karolherbst: but range is [600000, 1200000]
05:46 karolherbst: will try something near 1200000uv for now
05:47 karolherbst: 2352 MHz should be high enough :)
05:51 karolherbst: even the middle is too low for 2352 :/
05:59 karolherbst: (min +0.1 + max)/2 seems to work :/
06:03 pecisk: karolherbst: removed nouveau from black list, still got SCHED_ERR in dmesg, but Xorg loaded fine. lsmod nouveau shows it is used by something. xrandr --listproviders only Intel
06:03 karolherbst: okay
06:03 karolherbst: got 2561 MHZ working
06:03 karolherbst: pecisk: mhhh
06:03 karolherbst: pecisk: strange
06:03 karolherbst: xrandr should show nouveau
06:04 karolherbst: okay
06:04 karolherbst: please give me your current Xorg log
06:06 pecisk: karolherbst: http://fpaste.org/268412/42495170/
06:07 karolherbst: pecisk: mhh no dri3 support
06:07 karolherbst: sad
06:08 pecisk: karolherbst: what dri3 support means?
06:08 karolherbst: dri3 support
06:10 karolherbst: mupuf: anyway, pcie speed change works for your maxwell card :D
06:11 specing: up the speed to over 9000
06:11 karolherbst: specing: glxgears: 79077 frames in 5.0 seconds = 15815.382 FPS
06:11 specing: holyushit
06:12 pecisk: that's some fast gears
06:12 specing: karolherbst resized the glxgears window to 1x1? :D
06:12 mupuf: karolherbst: great to know!
06:12 karolherbst: I do that over ssh
06:12 karolherbst: mupuf: 2666 MHz works great
06:13 karolherbst: I just need to max out voltage
06:13 karolherbst: to 1306250uv
06:13 mupuf: super good!
06:13 karolherbst: but
06:13 karolherbst: two things: there are still two higher cstates
06:13 karolherbst: second: temp is around 51
06:13 karolherbst: which seems kind of too cool
06:13 mupuf: maxwell is crazy efficient
06:13 mupuf: and this is a discrete GPU
06:14 karolherbst: I know
06:14 karolherbst: but
06:14 mupuf: have to go!
06:14 karolherbst: what I try to say is, that the blob may use higher voltages
06:14 mupuf: need to eat and attend the conference
06:14 karolherbst: okay
06:14 karolherbst: have fun
06:14 karolherbst: will check the blob
06:16 pecisk: karolherbst: anything interesing from that Xorg log?
06:16 karolherbst: okay, got highest cstate working by setting pwm to 0x72
06:16 karolherbst: mupuf: notice after you are finished ;) cstate: 2718000, read out my nouveau: 2733750
06:17 karolherbst: it may, that nouveau just sets the clock too high, and therefore the voltage is a tiny bit too low
06:22 karolherbst: mupuf: cstate 5. pwm 0x1d: 8005 FPS, pwm 0x18: 7989 FPs
06:24 karolherbst: pwm 0x21: 8070 fps
06:24 karolherbst: it isn't much, but voltage seems to have an impact on performance on that card
06:27 karolherbst: there seem to be specific voltages, where there is a much bigger impact
06:27 karolherbst: cstate 6. pwm 0x22: 8700 fps, pwm 0x21: 8500 fps
06:28 karolherbst: 0x20: 8200 fps
06:31 karolherbst: mupuf: okay, your patches seems to be right in general, but it seems to be better to drive the core at higher voltages than min for 1. stability, 2. performance
06:32 RSpliet: karolherbst: there is no ssne reason I can think of why the voltage would impact performance
06:32 RSpliet: *sane
06:32 karolherbst: RSpliet: I know
06:32 karolherbst: but this is reproducible
06:32 karolherbst: but capped
06:33 karolherbst: when the voltage seems to be high enough, the performance nearly doesn't change
06:33 RSpliet: then I would really like to understand why
06:33 karolherbst: but if it gets nearer to the min value from the bios, the perf drops faster
06:33 karolherbst: don't know
06:33 karolherbst: I just changed the pwm reg value
06:34 karolherbst: will do some tests on my card too
06:35 RSpliet: gnurou: signal integrity checks on clock crossing domans, with adequate re-issue logic if unreliable?
06:35 pecisk: karolherbst: any ideas about xrandr not showing nouveau? :)
06:35 karolherbst: pecisk: no
06:35 karolherbst: RSpliet: maybe the latencies for instructions are incresing on low voltage?
06:36 RSpliet: that's clocked, shouldn't matter
06:36 karolherbst: mhh
06:36 RSpliet: I buy the "stability" argument, not the performance just like that ;-)
06:37 karolherbst: :D
06:37 karolherbst: I know
06:37 karolherbst: mhh, I need my nouveau ddx again :D
06:37 karolherbst: or is modesetting fine in general?
06:37 karolherbst: even on kepler
06:38 RSpliet: should be mostly fine, except for max clocks in certain situations
06:38 karolherbst: ohh nvm, it was my fault
06:38 karolherbst: second x server runs now
06:40 karolherbst: okay, it is the same on my card
06:40 karolherbst: but no big impact until now
06:41 RSpliet: karolherbst: fun exercise (I'd do it if I were at home :-D), see if you can find trace of the blob raising voltages after reclocking, and if there are any kind of counters that might indicate faulty requests
06:41 karolherbst: it is nearly insignificant on my card
06:42 karolherbst: RSpliet: the blob is pretty stupid about voltage
06:42 RSpliet: I doubt that
06:42 karolherbst: it sure is
06:42 karolherbst: temp seems to effect the voltage though
06:42 karolherbst: and current max clock setting
06:42 RSpliet: that's... incredibly clever
06:43 RSpliet: indicating they do have a hardware model
06:43 karolherbst: the former yes, the latter not so much
06:43 karolherbst: okay, got my perf impact now
06:43 RSpliet: try not to dismiss the nvidia engineers and developers as being "dumb", there's often good reasons why stuff behaves as it does ;-)
06:43 karolherbst: my card should crash any moment now :D
06:44 karolherbst: RSpliet: 12728.409 fps when a bit below min voltage
06:44 karolherbst: 13130.942 fps on somewhere between min and max
06:44 RSpliet: for arbitrary somewhere :-P
06:45 karolherbst: glxgears, yes
06:45 karolherbst: its reproducible though
06:45 karolherbst: and this is what matters ;)
06:46 karolherbst: this would also explain why the blob drives the card at higher voltage on lower temp
06:46 karolherbst: because there is an impact
06:47 karolherbst: for sane ranges we talk about 2-3% here
06:48 karolherbst: but before volting too high, we should implement dowvolting on high temp first
06:48 karolherbst: otherwise there might be upset user :D
06:52 karolherbst: will run heaven for the sake of "significance"
06:55 pecisk: karolherbst: just browsing around it seems that only intel Xorg driver is loaded and thus xrandr only sees it
06:58 karolherbst: pecisk: well the modesetting driver should also drive the nouveau card :/
06:58 karolherbst: mhhh 4.0
06:58 karolherbst: maybe the kernel is too old for the maxwell card?
06:58 karolherbst: I don't know
06:58 karolherbst: ohh no, its 4.2
06:58 karolherbst: should be fine
06:59 karolherbst: mhh
06:59 karolherbst: pecisk: did you restart X with nouvea being loaded?
07:00 pecisk: I restarted whole machine with nouveau being removed from blacklist
07:01 pecisk: lsmod nouveau shows it's here and it's being used
07:01 pecisk: however that's all I see
07:01 karolherbst: mhh okay
07:01 pecisk: ./proc/fb shows only Intel
07:01 karolherbst: at least something
07:01 karolherbst: ohhh
07:02 karolherbst: it should show both
07:02 karolherbst: then dmesg please
07:03 pecisk: karolherbst: https://drive.google.com/file/d/0B31QWsnd2TuWVEFlRWNfR0ZkZ00/view?usp=sharing here, warning, it's big due of big part of being SCHED_ERR at the end of it
07:05 karolherbst: ohhh
07:05 karolherbst: it seems like nouveau got never loaded?
07:05 karolherbst: there is a bunch of stuff missing
07:05 pecisk: lsmod shows it's loaded though :/
07:05 karolherbst: journald is really pain :/
07:05 karolherbst: 18 seconds are missing
07:06 karolherbst: I bet the dmesg command doesn't show everything anymore :(
07:06 pecisk: dmesg command is showing only last SCHED_ERR
07:06 pecisk: I could try to reboot and catch it as fast as I can
07:06 karolherbst: yeah, please do :D
07:07 karolherbst: or just blacklist it again
07:07 karolherbst: load nouveau
07:07 karolherbst: and do a dmesg
07:21 pecisk: karolherbst: modprobe nouveau overflows dmesg buffer
07:22 pecisk: with SCHED_ERR
07:22 pecisk: however this time journald have all seconds I think
07:23 pecisk: yeah, it's complete
07:24 pecisk: karolherbst: https://drive.google.com/file/d/0B31QWsnd2TuWLWlpdmFjQmFHcm8/view?usp=sharing
07:25 karolherbst: pecisk: nice, good
07:25 karolherbst: okay, this looks very bad
07:26 karolherbst: pecisk: what gpu was is again?
07:26 pecisk: 850M GTX
07:26 pecisk: 107M
07:26 karolherbst: ohh you got the DDR3 version?
07:27 pecisk: it seems so
07:28 karolherbst: https://gist.github.com/karolherbst/7732b1c3afd3eb959e54 this part is bad
07:28 karolherbst: ohhh mhh
07:29 karolherbst: seems like something is different than expected by nouveau
07:29 karolherbst: no clue though
07:29 karolherbst: pecisk: did you ever create a mmiotrace?
07:29 pecisk: nope :)
07:30 karolherbst: then you should learn how to :D
07:30 pecisk: I guess so
07:30 karolherbst: you need to trace the blob
07:30 karolherbst: instructions here: https://wiki.ubuntu.com/X/MMIOTracing
07:30 karolherbst: also you need the blob installed, which will mess up your isntallation :/
07:30 karolherbst: maybe fedora is better the
07:31 karolherbst: re
07:31 karolherbst: who knows
07:31 pecisk: I tried blob installed and be run, didn't succeed so far
07:31 karolherbst: mhhh
07:31 pecisk: but I will give another try
07:31 karolherbst: we could do following
07:31 pecisk: that was 8 months ago though
07:31 karolherbst: there might be a bumblebee package for fedora
07:31 pecisk: and I was very busy :)
07:31 pecisk: yeah
07:32 karolherbst: you need to install bumblebee for prop driver
07:33 karolherbst: ohh wow
07:33 karolherbst: the fedora wiki entry looks messy
07:33 karolherbst: you should follow "Install Bumblebee for non-standard or legacy NVIDIA proprietary drivers"
07:34 karolherbst: ohh wait
07:34 karolherbst: maybe not
07:34 karolherbst: "Install Bumblebee for NVIDIA proprietary drivers" should be better
07:35 pecisk: ok, I will try
07:37 pecisk: karolherbst: what bumblebee does?
07:38 karolherbst: enables you to use your second gpu whenever you want
07:38 karolherbst: like DRI_PRIME, just for the blob
07:38 karolherbst: but I am not that interessted in that
07:38 karolherbst: more in the setup
07:39 karolherbst: because it shouldn't mess up your graphic stack after installing the blob
07:40 pecisk: yeah, I got it
07:40 pecisk: I will give it a swirl in the evening
07:44 ttr_ppix: karolherbst, would you find it helpful for me to test out the nouveau git code on a 660 Ti ?
07:45 karolherbst: ttr_ppix: depends
07:48 karolherbst: if you mean the gddr5 branch, then usually yes
08:02 ttr_ppix: karolherbst, yes it is the model that comes with 2gb GDDR5
08:03 karolherbst: ttr_ppix: please double check that you are using the gddr5 branch
08:04 ttr_ppix: karolherbst, you mean the appropriate nouveau branch?
08:05 karolherbst: yes, not master, but gddr5
08:07 ttr_ppix: great, what is the reccomended linux kernel/xorg version ? i'm on ubuntu 14.04.3 LTS currently
08:08 karolherbst: mhhh I am using 4.1
08:08 karolherbst: mhhh
08:08 karolherbst: I get the strange feeling your kernel might be too old
08:08 karolherbst: and I didn't plan to backport it
08:08 karolherbst: should be kind of easy though
08:09 karolherbst: ttr_ppix: are you using 3.13?
08:13 ttr_ppix: karolherbst, currently yes, 3.13 with versions 3.16 and 3.19 available as potential upgrade paths
08:13 ttr_ppix: and of course, other versions available from PPA sources
08:14 karolherbst: mhhh
08:14 karolherbst: I doubt it will work with 3.13
08:14 karolherbst: I mean it shouldn't compile, maybe it does
08:14 karolherbst: either way
08:14 karolherbst: I guess you will encounter less nouveau troubles with 3.19 anyway
08:15 karolherbst: 3.19 might work
08:24 ttr_ppix: karolherbst, i will give it a shot with 3.19 and report back
08:27 imirkin: ttr_ppix: i think there's a bit of a disconnect between you and karolherbst
08:28 imirkin: ttr_ppix: if you want to test his patches, you have to build your own kernel
08:28 karolherbst: imirkin: why?
08:29 karolherbst: he could simply compile my branch against 3.19
08:29 karolherbst: or not?
08:29 imirkin: your branch will only work against 4.3-rc1 as i recall (at least not without modifications)
08:29 karolherbst: nope
08:29 karolherbst: I use 4.1
08:30 karolherbst: I still used the 4.1 compatible version of the rework
08:30 imirkin: ah, then 3.19 might be fine... there was a range of kernels that it worked with for a while
08:31 imirkin: i thought your branch was based on the latest, and there have been drm changes
08:31 karolherbst: the master branch got forced pushed after the rework landed
08:31 karolherbst: before it was 4.1 compatible
08:31 karolherbst: now it needs newer drm
08:32 karolherbst: I just tried to rebase on newest master, because of the updated hack for my gpu
08:32 karolherbst: and just gave up because of the drm thingy
08:32 karolherbst: so my master branch is like the "old" rework version
08:32 ttr_ppix: i guess i would like to test it whatever manner would provide you with the most valuable feedback, if testing with 3.16 or 3.19 would be more valuable than 4.0 or 4.1 then that is what i will attempt
08:32 karolherbst: ttr_ppix: I prefer not to bother you with much work :D
08:32 karolherbst: if 3.19 works it is fine
08:33 karolherbst: if not, then we know that and have to move on to newer kernels
08:33 karolherbst: it won't land before 4.4 anyway
08:33 ttr_ppix: karolherbst, then that is what i'll do, thank you for your work on Nouveau!
08:37 karolherbst: no need to thank me, I mostly did it for myself :p
08:39 ttr_ppix: one final question: will I need to upgrade xorg beyond 1.15.1
08:40 ttr_ppix: upgrading to 1.17.1 should be trivial, fwiw
08:41 imirkin: X server shouldn't matter
08:41 imirkin: ttr_ppix: you'll still have to build a new nouveau module btw, just want to make sure you realize that.
08:46 pecisk: bb
08:51 karolherbst: ttr_ppix: installing the new module might be painfull as well, so even after installing the new module don't be sad if it doesn't work, there are several reasons why it doesn't work then ;)
10:47 ttr_ppix: imirkin, all i can say is i will give it an honest effort and report back all my fun issues if/when encountered
10:47 ttr_ppix: karolherbst, thank you for the heads up, always exciting entering uncharted territory for the good of the cause :)
10:48 karolherbst: I see
10:48 karolherbst: ttr_ppix: so were you able to compile my branch on 3.19?
10:50 ttr_ppix: karolherbst, my ubuntu box is home and has ssh turned off at the moment, i'll need to give it a shot tonight when i get home from the office
10:50 karolherbst: okay, nice
10:50 ttr_ppix: and remember to reenable ssh while i'm at it...
12:19 karolherbst: ohhhh well
12:20 karolherbst: for kepler pcie speed change we have to do what is needed on fermi (partly) and additional stuff for kepler ...
12:20 karolherbst: somehow I was too optimistic with "we only have to poke into one reg" :D
12:28 mupuf: karolherbst: hehe, that's never THAT easy
12:28 mupuf: it is still pretty simple though :)
12:28 karolherbst: not anymore
12:28 karolherbst: on kepler there are like two regs for pcie cap speed
12:28 karolherbst: one used also on fermi
12:28 karolherbst: the actual cap speed is the lowest value of both
12:29 karolherbst: so you have to check both values
12:29 karolherbst: and write both values
12:29 karolherbst: mupuf: saw my comments about your maxwell card ;)
12:30 mupuf: about my maxwell being able to change pcie speed?
12:31 karolherbst: no, being able to run at highest cstate
12:31 mupuf: oh, what did you do?
12:31 karolherbst: pwm value just needed to be raised b 0x1
12:31 karolherbst: 0x71 was bad
12:31 karolherbst: 0x72 seems fine
12:31 mupuf: lol
12:31 karolherbst: I have a theory already why
12:32 karolherbst: mupuf: cstate: 2718000, read out my nouveau: 2733750
12:32 karolherbst: *by
12:32 karolherbst: maybe these 15MHz more is too much
12:32 mupuf: hmm
12:32 karolherbst: the steps are usually that big
12:33 karolherbst: and pwm needs to be adjusted by 0x3 or something
12:33 mupuf: yeah, I see
12:33 karolherbst: its prettsy tight on your card
12:33 karolherbst: also
12:33 karolherbst: voltage impacts perf
12:33 karolherbst: if voltage gets too low, there is even a noticable pref impact
12:33 mupuf: really? Are you REALLY sure about that?
12:33 karolherbst: yes
12:33 karolherbst: wait a second
12:34 karolherbst: mupuf: cstate 5. pwm 0x1d: 8005 FPS, pwm 0x18: 7989 FPs cstate 6. pwm 0x22: 8700 fps, pwm 0x21: 8500 fps
12:34 mupuf: that suggests a VERY complex design
12:34 karolherbst: I got it actually down to 7800 fps on 6
12:34 mupuf: that is just the variance
12:34 karolherbst: was at 0x16 pwm or something
12:34 mupuf: this is a cpu-linmited case
12:34 specing: if voltage gets too low, low voltage detect will kick in and kill clock to the chip
12:34 mupuf: do not trust this
12:34 mupuf: run heaven
12:34 karolherbst: ohhh okay
12:34 karolherbst: I also made some tests on my card
12:34 mupuf: specing: and how do you do that fast-enough?
12:35 karolherbst: and in general this is right, but the effect varies a lot
12:35 karolherbst: didn't get a bigger change than 3%
12:35 karolherbst: but there is a change
12:35 mupuf: karolherbst: I doubt this is anything but an artefact
12:35 karolherbst: mupuf: when I use your patches and put +0x9 pwm on top, I get more perf
12:35 karolherbst: around 1% in heaven
12:35 karolherbst: :D
12:35 mupuf: which benchmark
12:35 mupuf: ?
12:35 karolherbst: yes
12:36 karolherbst: glxgears also shows a stable change
12:36 karolherbst: but there it's more like e%
12:36 karolherbst: 3%
12:36 mupuf: hmm, I will doubt it until I check it pretty seriously and acquire serious data
12:36 mupuf: not 10 data points
12:36 mupuf:will not trust humans for this kind of results
12:37 karolherbst: I know
12:42 Karlton: /quit
12:42 specing: mupuf: magic
12:43 imirkin_: Karlton: there's no way out
12:45 Karlton: yeah I am about to hardcode this client so that it also takes / instead of just : as a command
12:45 karolherbst: :D
12:48 karolherbst: mupuf: but basically maxwell core reclocking seems to work
12:48 karolherbst: as long as the voltage is high enough
12:48 karolherbst: this is the kepler/maxwell part for pcie speed changes: https://github.com/karolherbst/nouveau/commit/8f5c0d977e3e838b5eaf5fd452bacbb3a7907270
12:49 karolherbst: and I think I will be killed for code like gk104_get_pcie_version_supported
12:49 karolherbst: :D
12:53 mupuf: karolherbst: ben remembers that we do not parse the clock tree properly
12:53 mupuf: so, we will need to check that
13:22 karolherbst: mupuf: ohh okay
13:22 karolherbst: on my card are the lower clocks missing
13:25 joi: weird, I can reproduce fifo read fault in witcher2 under apitrace, but can't reproduce it when replaying
13:25 karolherbst: joi: the fault should also come without apitrace
13:26 joi: yes, I know
13:26 karolherbst: joi: did you say that you use the gog or steam version?
13:26 joi: steam version
13:26 karolherbst: and you don't get the issue I have?
13:27 joi: what issue?
13:27 karolherbst: https://bugs.freedesktop.org/attachment.cgi?id=117061
13:27 joi: nope
13:27 karolherbst: though I think you need some saves otherwise the issue won't be there
13:27 karolherbst: I think its a game issue though
13:27 karolherbst: because with a newer unreleased build I don't get those
13:36 pecisk: karolherbst, if you don't use steam witcher 2 beta version, yes, most likely game is broken
13:36 karolherbst: :D
13:36 karolherbst: so I should use the beta branch?
13:51 karolherbst: mupuf: could you imagine, that there might be a table with clock min, clock step, volt step, max clock? Or something like that?
13:52 mupuf: I doubt it
13:52 mupuf: the voltage mapping table is probably where everything is
13:52 mupuf: and we need to prove it first
13:53 karolherbst: yeah I know, but there is something else, as I said, the blob uses lower clocks than nouveau does
13:54 karolherbst: maybe the cstep table tells us, up to this clock use this voltage or something, because I don't find any information for clocks between 135 and 405MHz in my bios
13:54 karolherbst: the blob uses the same pwm value for those though (0x38)
13:55 mupuf: have fun REing that!
13:55 karolherbst: maybe one of those unknown bits mean "also use for lower clocks"?
13:55 karolherbst: I can't fake my vbios :(
13:55 karolherbst: maybe I should debug this first :/
13:57 mupuf: yes!
13:58 karolherbst: can I upload the vbios through other means or whould I have to code that first
13:59 karolherbst: mhh maybe I should test first if I can mess nouveau up
13:59 karolherbst: nvafakebios should be fine for nouveau?
13:59 mupuf: yes, try with nouveau first
14:00 karolherbst: where do I have to disable the pstates, in the PM_Mode table or cstep table?
14:00 karolherbst: or boost table
14:01 karolherbst: or all of them
14:12 karolherbst: that went bad
14:12 mupuf: pstate?problably the first one
14:12 mupuf: :D
14:12 mupuf: what happened/
14:12 mupuf: ?
14:12 karolherbst: nvafakebios crashed my laptop
14:12 pecisk: karolherbst, got bumblebee running
14:13 karolherbst: pecisk: intel still works after reboot?
14:13 karolherbst: mupuf: ohh I don't know if nouveau was loaded or not
14:13 karolherbst: maybe it wasn't?
14:14 karolherbst: maybe it was
14:14 karolherbst: is that bad?
14:15 mupuf: it is never supposed to crash
14:15 pecisk: karolherbst, it seems module to be loaded and used
14:17 pecisk: not again
14:19 karolherbst: mhhh
14:19 karolherbst: why
14:19 karolherbst: somehow something bad happens
14:20 karolherbst: mupuf: any idea? my laptop crashes whenever I try to upload my vbios
14:20 karolherbst: without any changes
14:20 mupuf: hmm
14:21 pecisk: in not so related news, AMD finally broke silence about Vulkan, yay
14:21 karolherbst: should I rather use a vbios file read from nouveau itself?
14:21 pecisk: karolherbst, evertyhing works for me so I can try to poke some registers
14:22 karolherbst: pecisk: follow mmiotrace instructions
14:22 karolherbst: but instead of starting X or anything like that
14:22 karolherbst: you can simply do "optirin -b none bash"
14:22 karolherbst: exit
14:22 karolherbst: stop trace
14:22 karolherbst: optirun
14:22 pmoreau: pecisk: What did they announce regarding Vulkan?
14:24 karolherbst: mupuf: ohhh there is a certificate on my bios, is that normal?
14:24 pecisk: pmoreau, having prototype already, will be closed first, then open sourced, dri3 using drm
14:24 karolherbst: two certs to be exact
14:25 pmoreau: pecisk: Ok!
14:25 karolherbst: ohh okay, seems normal
14:26 specing: " will be closed first, then open sourced"
14:26 specing:lol
14:27 karolherbst: forget about mesa, use vulkan :p
14:30 pecisk: karolherbst: so I start to trace and what sall I do...just restart gdm for example?
14:30 karolherbst: no
14:31 karolherbst: you have a hybrid gpu setup
14:31 karolherbst: it is much easier there
14:31 karolherbst: you just start the trace
14:31 karolherbst: run "optirun -b none bash"
14:31 karolherbst: exit
14:31 karolherbst: stop the trace
14:31 karolherbst: then you are done
14:31 pecisk: ok, trying out
14:32 karolherbst: mupuf: any idea what I could do?
14:35 mupuf: karolherbst: hmm
14:35 mupuf: I never had any problem like that before
14:35 karolherbst: I know that my laptop didn't crashed before :D
14:36 mupuf: try doin it without X running
14:36 karolherbst: mhhh, k
14:36 pecisk: karolherbst: ok, this froze my laptop for 10 secs, but I got a trace
14:36 karolherbst: okay, it worked on a tty, but now I am using a new bios file
14:37 karolherbst: pecisk: nice
14:37 karolherbst: how big is it?
14:37 karolherbst: mupuf: seems like that you should use a vbios file fetched through nouveau debugfs
14:37 karolherbst: I don't know how I get the other one
14:37 karolherbst: but it was smaller
14:39 mupuf: oh, try one extracted with nvagetbios
14:39 mupuf: nvagetbios -s prom
14:39 pecisk: 27M
14:39 pecisk: karolherbst: 27M
14:40 pecisk: will put on google drive
14:40 karolherbst: mupuf: the one through debugfs works though
14:40 karolherbst: pecisk: wait
14:40 karolherbst: run it through xz first :D
14:40 karolherbst: xz -9
14:40 karolherbst: now I will try to change the voltage of the lowest cstate :)
14:41 karolherbst: ohh wait
14:43 pecisk: karolherbst: mmiotrace dump is here https://drive.google.com/file/d/0B31QWsnd2TuWUUxSX2U1ZjRMNE0/view?usp=sharing
14:44 pecisk: karolherbst: I marked loading of bash with "Bash Now"
14:44 karolherbst: don't do that
14:44 karolherbst: now I have to remove that :/
14:44 pecisk: karolherbst: sorry
14:44 karolherbst: what was your card again
14:44 karolherbst: GM107?
14:45 pecisk: karolherbst: GM107M
14:45 pecisk: 750 GTX M
14:45 karolherbst: then I also need your vbios
14:46 pecisk: how to fetch it for binary driver?
14:46 karolherbst: ohh allthough this is a mark about bash
14:46 karolherbst: should be fine?
14:46 karolherbst: don't know
14:47 karolherbst: pecisk: nvagetbios -s prom
14:47 pecisk: envytools again? :)
14:47 karolherbst: yeah
14:47 karolherbst: the trace looks okayish, can't tell for sure though
14:49 karolherbst: mupuf: could you ask around if somebody has a pcie v1 only board and a kepler card?
14:49 karolherbst: and a non pcie v1 only board
14:49 karolherbst: ohh maxwell would be okay too
14:52 pecisk: karolherbst: Invalid signature(0x55aa). You may want to try another retrieval method. but it extracted 1M
14:52 karolherbst: pecisk: you have to start the card first
14:53 karolherbst: usually your card should be off now
14:53 karolherbst: so
14:53 karolherbst: best if you just do optirun -b none bash
14:53 karolherbst: then extract bios
14:53 karolherbst: exut
14:53 karolherbst: *exit
14:54 karolherbst: as long as nouveau won't work you can now use bumblebee to use your nvidia card with the prop driver, also it takes care of turning your card on/off
14:54 karolherbst: nouveau should be still blacklisted for now
14:57 pecisk: karolherbst: under optirun, command doesn't complain but doesn't extract vbios neither, it stays 0
14:58 karolherbst: mhhh
15:00 karolherbst: pecisk: try this then: echo 1 > /sys/bus/pci/devices/<pciid>/rom; cat /sys/bus/pci/devices/<pciid>/rom > vbios.rom; echo 0 > /sys/bus/pci/devices/<pciid>/rom
15:00 karolherbst: you have to select the right pciid
15:00 karolherbst: but that should be easy
15:01 karolherbst: mupuf: no luck
15:01 karolherbst: even nouveau doesn't see it
15:01 karolherbst: I did nvafakebios -e 808d:1a vbios.rom
15:02 karolherbst: Edit offset 0x808d from 0xa to 0x1a (hex, 8 bits)
15:02 karolherbst: but cstate is still at 10 voltage
15:02 pecisk: karolherbst: cat gives me input output error
15:02 karolherbst: :/
15:02 karolherbst: what is with that card....
15:02 pecisk: I run it under optirun though
15:02 karolherbst: yeah okay well
15:02 karolherbst: we do it without the blob now
15:02 karolherbst: exit
15:03 karolherbst: cat /proc/acpi/bbswitch
15:03 karolherbst: this should tell you OFF
15:03 karolherbst: if OFF, echo ON > /proc/acpi/bbswitch
15:04 karolherbst: then try nvagetbios again
15:04 pecisk: karolherbst: have no bbswitch there
15:04 karolherbst: mhhhh
15:04 karolherbst: wait
15:04 karolherbst: is it loaded inside lsmod?
15:04 pecisk: yes
15:05 karolherbst: ....
15:05 karolherbst: dmesg | grep bbswitch
15:05 pecisk: it uses only drm though
15:05 pecisk: no bbswitch in dmesg
15:05 karolherbst: ohhh man :/
15:06 karolherbst: modinfo bbswitch
15:06 pecisk: module not found
15:06 karolherbst: funny
15:06 karolherbst: okay, then the card should be on?
15:06 pecisk: yes, it is
15:06 karolherbst: maybe switcheroo is there
15:07 karolherbst: cat /sys/kernel/debug/vgaswitcheroo/switch
15:07 pecisk: nope
15:07 karolherbst: oh well
15:07 karolherbst: but then you should be able to get the vbios file without issues
15:07 pecisk: I have package bbswitch but no module
15:07 karolherbst: maybe the first one is indeed fine
15:07 pecisk: it felt like it is
15:08 karolherbst: the with " Invalid signature(0x55aa). You may want to try another retrieval method. but it extracted 1M"
15:08 karolherbst: try to pass the vbios file to nvbios
15:08 karolherbst: it should print a lot of stuff
15:09 karolherbst: mupuf: any idea how I can debug this stupid vbios uploading mess on my card?
15:09 pecisk: http://fpaste.org/268690/42527760/
15:09 pecisk: not a lot of stuff
15:10 karolherbst: mhhh
15:11 pecisk: optirun runs, I can run glxinfo and it shows it's Nvidia corp
15:11 mupuf: karolherbst: sorry, still at the conference
15:11 mupuf: about to take part in a panel on how to get involved in the open source community
15:11 karolherbst: pecisk: yeah there is no problem with that, but well
15:11 karolherbst: :)
15:11 karolherbst: it's easy, write patches, submit patches :p
15:12 mupuf: :)
15:12 pecisk: heh, I wish
15:13 pecisk: karolherbst: without vbios not much sense from that dump?
15:13 karolherbst: ohhh, mhh I don't know, maybe maybe not
15:13 karolherbst: who knows
15:14 pecisk: karolherbst: in case there's that 1M file https://drive.google.com/file/d/0B31QWsnd2TuWamJwVldaTDFESHM/view?usp=sharing
15:14 karolherbst: ohh yeah, it is empty
15:15 karolherbst: a whole file with nothing
15:15 pecisk: well, sucks
15:16 karolherbst: try nvagetbios -s pramin
15:16 mupuf: pramin does not work anymore starting from kepler
15:16 karolherbst: :(
15:16 karolherbst: ohh well
15:16 karolherbst: pecisk: okay then this
15:17 karolherbst: be sure nvidia is not loaded
15:17 karolherbst: load nouveau
15:17 karolherbst: cat /sys/kernel/debug/drm/1/vbios.rom > vbios.rom
15:17 karolherbst: I hope it is the right path
15:18 karolherbst: ohhhh
15:18 karolherbst: maybe nouveau messes up, because it can't read the vbios? :D
15:18 karolherbst: well we will see that in a moment
15:18 pecisk: hmmmm, how to remove nvidia for a moment
15:20 karolherbst: ohhh
15:20 karolherbst: did you stop all optirun shells?
15:20 pecisk: yes
15:20 karolherbst: mhhhh
15:20 pecisk: it still shows something uses it
15:20 karolherbst: then there is still an open shell
15:20 karolherbst: or maybe the fedora packages has messed up configs
15:20 karolherbst: ........
15:21 karolherbst: pecisk: I need /etc/bumblebee/bumblebee.conf then
15:22 pecisk: http://ur1.ca/ntah4
15:23 karolherbst: ..... how, how can somebody do that: "TurnCardOffAtExit=false"
15:23 karolherbst: of course it should be true
15:23 karolherbst: ....
15:23 karolherbst: oh man
15:23 karolherbst: anyway
15:23 pecisk: it's third party package
15:24 karolherbst: I know
15:24 pecisk: so it left it on despite me exiting
15:24 pecisk: funsies
15:24 karolherbst: anyway
15:24 karolherbst: the second X server should be stoped
15:24 karolherbst: how many uses does nvidia have?
15:24 pecisk: only 1
15:24 karolherbst: ....
15:25 karolherbst: I bet your main X server just grabed that card
15:25 pecisk: nvidia 8560640 1
15:25 pecisk: drm 335872 11 i915,drm_kms_helper,nvidia
15:25 pecisk: no bets, because I agree
15:25 karolherbst: :(
15:25 karolherbst: what the hell
15:26 karolherbst: pecisk: add a xorg.conf file
15:26 karolherbst: with ServerFlags entry: Option "AutoAddGPU" "false"
15:27 pecisk: and reboot?
15:27 karolherbst: mhh well, that is more tricky then
15:28 karolherbst: but yeah, try a reboot
15:28 pecisk: bb
15:31 karolherbst: oh wow, I got mentioned :O
15:41 karolherbst: this is insane. antichmaber 0a: 38 fps, 0f: 72 fps...
15:46 pecisk: karolherbst, first, such flag isn't known at least for this xorg
15:46 pecisk: anyway, nvidia module isn't loaded and I loaded nouveau
15:46 pecisk: where I could find vbios?
15:47 imirkin_: pecisk: /sys/kernel/debug/dri/1/vbios.rom
15:48 pecisk: well, there's no 1 in dri, 0 is i915
15:48 pecisk: nouveau module is loaded
15:48 pecisk:suspects he is cursed
15:48 imirkin_: pecisk: pastebin dmesg
15:51 pecisk: ahhh, blacklisted at booting
15:52 karolherbst: pecisk: shouldn't matter
15:52 karolherbst: if you load it
15:53 karolherbst: it should be in debugfs
15:53 imirkin_: unless you use modprobe and you have some shit like "nouveau.modeset=0"
15:55 pecisk: anyway, got bios
15:55 pecisk: bb
16:00 karolherbst: some gddr5 test results: https://gist.github.com/karolherbst/7b4e565970fa34b23e8c
16:02 pecisk: karolherbst: this is vbios I got with nouveau loaded trough /sys/kernel/debug/dri/1/vbios.rom https://drive.google.com/file/d/0B31QWsnd2TuWZlc0dWxaZW5sa1k/view?usp=sharing
16:03 karolherbst: seems fine, thanks
16:03 karolherbst: pecisk: and then nvapeek 101000
16:03 imirkin_: joi: btw, i dunno if this is the issue for witcher2 invalid addresses, but i've noticed that there's a bug in nouveau re updating texture buffers... if one gets invalidated, then we never update the address in the TIC. i've sent a patch for that, will probably push soon.
16:04 pecisk: karolherbst: 00101000: 00400082
16:05 karolherbst: pecisk: thanks a lot
16:06 pecisk: karolherbst: hopefully anything useful
16:07 karolherbst: should be
16:07 pecisk: going to sleepin
16:08 pecisk: see ya
16:11 karolherbst: imirkin_: updated my tests with 0f+ (pcie) https://gist.github.com/karolherbst/7b4e565970fa34b23e8c
16:11 karolherbst: the only outstanding improvement over 0f is talos
16:11 imirkin_: borderlands 41->46 sounds nice too
16:11 imirkin_: but yeah, the talos improvement is huge
16:12 imirkin_: nearly 50%
16:13 karolherbst: the borderlands one is because of prime
16:13 karolherbst: don't forget that
16:13 karolherbst: the higher the fps, the higher the improvement
16:13 imirkin_: ... not as a percentage, presumably
16:13 karolherbst: nope
16:13 karolherbst: will add glxgears and glxspheres64 tests
16:16 karolherbst: imirkin_: last entry: https://gist.github.com/karolherbst/7b4e565970fa34b23e8c
16:16 imirkin_: heheh
16:16 karolherbst: 1000 MPixels/s
16:17 imirkin_: what does the blob get?
16:17 imirkin_: although it's not entirely fair since the tech to move the image over is probably different
16:17 karolherbst: yeah
16:17 karolherbst: over bumblebee I get maybe 500 fps? maybe 400
16:18 karolherbst: didn't ran it inside a X server though
16:18 karolherbst: may do it after checking glxgears
16:19 karolherbst: imirkin_: check glxgears out: https://gist.github.com/karolherbst/7b4e565970fa34b23e8c
16:20 imirkin_: karolherbst: makes sense
16:20 imirkin_: glxgears largely measures command submission/etc overhead
16:20 imirkin_: the actual rendering is a no-op
16:20 karolherbst: yeah
16:20 karolherbst: but gputest benchmarks were also happy with higher pcie speed
16:21 imirkin_: well e.g. the gputest triangle benchmark is the same
16:21 imirkin_: i.e. rendering = no op
16:21 karolherbst: yeah
16:21 karolherbst: 700 => 2200 fps
16:22 imirkin_: so it's all overhead
16:22 karolherbst: furmark 33 => 37 fps
16:27 karolherbst: ohhhh, why can't I start a second X server now? :/
16:27 karolherbst: (EE) NOUVEAU(0): [drm] failed to set drm interface version. (EE) NOUVEAU(0): [drm] error opening the drm (EE) NOUVEAU(0): 892:
16:30 karolherbst: and why can't I switch to tty now? :/
16:35 karolherbst: yeah lol, after some tries it magically works
16:37 karolherbst: glxspheres64 on second X server directly: 1500 fps
16:38 karolherbst: pcie speed nearly no effect
16:39 imirkin_: makes sense
16:41 karolherbst: sanctum 2 seems to be a pretty bad port
16:41 karolherbst: the perf is just terrible on mesa
16:42 imirkin_: welllll
16:42 imirkin_: note that there's been like no perf tuning
16:42 imirkin_: or rather... very little... and not for a while
16:42 imirkin_: i haven't really been looking at perf
16:42 imirkin_: because i don't really have a way to
16:42 karolherbst: I see
16:42 imirkin_: and all my GPUs are slow as balls anyways
16:43 imirkin_: the GT 240 i have is probably by far and away the fastest one
16:43 karolherbst: I somehow think it is useless to do that if you don't know the latencies of instructions and so on
16:43 imirkin_: and it'd be a whole lot faster if i could reclock it
16:43 imirkin_: welll
16:43 imirkin_: there's a lot more to it
16:44 imirkin_: like resource placement
16:44 imirkin_: stalls
16:44 imirkin_: etc
16:44 karolherbst: I see
16:44 glennk: good thing the chips are jam packed with perf counters
16:44 imirkin_: like if you're effectively sleeping in the driver, no amount of better instruction scheduling is going to solve that problem
16:44 karolherbst: I kind of failed with my reducing live values in the end
16:44 imirkin_: glennk: sure, but i have no way to use them
16:44 karolherbst: in the end I bumped max reg usage in one shader form 35 to 150
16:45 imirkin_: glennk: nor would i know what to do with them if i had access to them
16:45 karolherbst: :D
16:45 karolherbst: I would be interessted in cases where a game is memory limited
16:45 imirkin_: karolherbst: errr... you only have 64 regs
16:45 karolherbst: and the core is doing "not much"
16:45 karolherbst: imirkin_:
16:45 karolherbst: imirkin_: I compiled for gk110
16:45 imirkin_: oh ok
16:45 karolherbst: thought it would make more sense
16:45 karolherbst: :D
16:46 karolherbst: but there were practially only a 10% perf impact on heaven :/
16:46 imirkin_: you have a gk110/gk208?
16:46 karolherbst: allthough all the shaders were spilling all the time
16:46 karolherbst: no
16:46 karolherbst: I just compiled it that way
16:46 imirkin_: sure, but how do you know what the perf impact was
16:46 karolherbst: then I tested for my gpu
16:46 karolherbst: because that makes sense
16:46 karolherbst: if on gk110 a shader uses like 150 regs
16:47 karolherbst: it will use 62 on my + tons of spilling
16:47 karolherbst: or not?
16:47 glennk: imirkin_, https://perfc.wordpress.com/ ?
16:48 imirkin_: glennk: which is all pretty new
16:48 imirkin_: and apparently no GUI support
16:48 imirkin_: aaaaan... apitrace != actual app perf
16:48 glennk: well, the gpu side it can measure reasonably
16:49 imirkin_: sure, but it may show that there are stalls where there in fact are none
16:49 imirkin_: since data takes time to compute
16:49 glennk: well all profilers introduce measurement errors
16:50 imirkin_: but it's not a profiler
16:50 imirkin_: a profiler profiles the runnign application
16:50 imirkin_: this replaces a trace and profiles that
16:50 glennk: the difference to the driver though is pretty minimal in most cases
16:51 karolherbst: mhhh
16:51 karolherbst: I highly doubt that
16:51 karolherbst: it is not that like games don't use any cpu at all
16:52 karolherbst: I think as long as there are none async GL calls in the driver it really makes a difference
16:53 glennk: i'm sort of assuming both the game and the profiler manage to not cpu bottleneck
16:53 karolherbst: mhhh
16:53 karolherbst: you are too optimistic :D
16:53 glennk: or perhaps i've just run too many traces by now :-)
16:53 karolherbst: think about all those eon games or games running through wine and everything else
16:54 karolherbst: usually most AAA titles have a pretty high CPU load too
16:54 glennk: and thats a constant you don't have any control over, so don't bother measuring it :-)
16:55 karolherbst: yeah but it matters for the gpu load somehow
16:55 karolherbst: it is not like that every gl command is executed right away, but there is most likle some other cpu work in between
16:55 glennk: see my previous assumption
16:56 karolherbst: yeah well, driver overhead is more important in such cases
16:58 glennk: for instance one could use the gpu counters to measure the number of vram read/writes during a frame and compare various tiling etc options
16:59 glennk: the cpu overhead won't have any effect on that kind of measurement
16:59 karolherbst: won't we see it from the generated gpu binaries?
17:00 glennk: sorry, but i have no idea what you are referring to?
17:00 karolherbst: vram read/writes
17:01 glennk: yes, lets solve the turing halting problem first
17:01 karolherbst: it is not like we already know when the driver is doing vram read/writes, or am I wrong?
17:01 glennk: you are approximately somewhere near alpha centauri if the right answer is close to the moon :-)
17:02 karolherbst: still pretty close :)
17:02 karolherbst: :p
17:03 glennk: i'm talking the number of actual reads/writes performed by the gpu's memory controller
17:03 karolherbst: I see
17:03 glennk: things like hierarchal z, tiling, frame buffer compression etc would affect that
17:05 glennk: checking some other counters will tell you if a draw call is limited by shader or some other pipeline stage
17:06 karolherbst: I see
17:26 karolherbst: okay, faking vbios, why doesn't it work ...
17:45 karolherbst: yay, found another PPCI_2 reg :)
18:01 imirkin_: one perf thing i'm aware of that we're not doing is "zcull". i don't know what it is, or how to enable it.
18:01 imirkin_: and it might need kernel-side support too, not sure
18:03 karolherbst: mhhh
18:03 karolherbst: sounds vague
18:03 karolherbst: ohh this is z-buffering related?
18:03 imirkin_: well, i'm sure it's depth-related somehow
18:04 imirkin_: but... how
18:04 karolherbst: "In rendering, z-culling is early pixel elimination based on depth, a method that provides an increase in performance when rendering of hidden surfaces is costly. It is a direct consequence of z-buffering, where the depth of each pixel candidate is compared to the depth of existing geometry behind which it might be hidden."
18:04 karolherbst: ?
18:05 imirkin_: yes :)
18:05 karolherbst: okay
18:05 imirkin_: but to make the hw do it
18:05 imirkin_: you don't just flip a switch
18:05 imirkin_: there's some sort of buffer, etc
18:05 imirkin_: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n8
18:05 imirkin_: i guess calim gave it a shot back in the day but decided not to use it
18:06 karolherbst: seems that way
18:08 karolherbst: oh wow, don't tell me I found another reg to mess up link speed
18:09 imirkin_: i'm sure there are a ton to mess it up
18:09 imirkin_: but just one to make it right ;)
18:09 karolherbst: I already does the stuff the blob does in a "sane" state
18:09 karolherbst: this was like the easiest part
18:10 karolherbst: ohh wow, reg that changes values after write to another, nice
18:11 karolherbst: mhh, maybe wrong alarm?
18:11 karolherbst: mhh, what does this bit do
18:12 karolherbst: maybe flushes the pcie state to the hardware?
18:12 karolherbst: mhh
18:17 karolherbst: I am pretty sure I found the WIDTH bits though
18:18 karolherbst: ohh, no, it is something else indeed
19:15 mrnuke: imirkin_: guess what, I can run 3x4k on maxwell, buuuut
19:15 mrnuke: imirkin_: BUT, I cannnot have 3 landscape side-byside
19:15 imirkin_: lol
19:15 mrnuke: I can have two side-by-side and one on top
19:16 imirkin_: what's the res on each one? 3840?
19:16 mrnuke: 3840x2160, yeah
19:16 imirkin_: so a total of 11520
19:16 imirkin_: hmmmm
19:16 imirkin_: should fit.
19:16 imirkin_: what complains?
19:17 imirkin_: (max is 16384 for GPU rendering)
19:17 mrnuke: KDE kscreen GUI. Says something not supported by GPU
19:17 imirkin_: with xf86-video-nouveau or -modesetting?
19:17 mrnuke: yeah, and yeah
19:18 mrnuke: well, modesetting is on
19:18 imirkin_: i mean xf86-video-modesetting
19:18 imirkin_: as the xorg ddx
19:18 imirkin_: hmmmm... looks like we set the max mode config to 8192
19:18 imirkin_: can you make a minor patch?
19:19 imirkin_: drm/nouveau/nouveau_display.c:nouveau_display_create
19:19 imirkin_: add a else if (drm->device.info.family < NV_DEVICE_INFO_V0_FERMI) and stick the 8192 into that, otherwise make it 16384
19:19 imirkin_: [let me know if that makes no sense, i can make the patch for you]
19:21 imirkin_: basically fermi+ can do 16k
19:21 mrnuke: I can try it after this weekend, but right now I don't have a very good way of transferring data to and from said machine
19:22 imirkin_: can you build a kernel on the box?
19:22 mrnuke: nope
19:22 imirkin_: it's a 2-line patch
19:22 imirkin_: ok
19:23 mrnuke: linux is on a USB stick on that machine. I know, far from ideal, but I just wanted to do a quick test
19:24 imirkin_: well this is the patch: http://hastebin.com/puyepufaca.diff
19:24 imirkin_: totally untested
19:24 imirkin_: should apply on top of 4.3-rc1
19:26 mrnuke: imirkin_: sweet, I'll dick around with building that kernel and let you know how it goes
19:26 mrnuke: right now it's a maze moving the mouse from onse screen to another
19:26 imirkin_: well, if you have a different kernel, it should be a very similar patch
19:27 imirkin_: from the sounds of it, you should be capable of adapting it if need be
19:27 mrnuke: It's just building a kernel. I have a degree in math and physics. I think I can handle it :)
19:28 imirkin_: i meant adapting the patch
19:28 imirkin_: dunno about your math and physics degrees, but mine didn't cover kernel compilation
19:29 mrnuke: just multiply the wave function by its complex conjugate. You'll get to building the kernel from there
19:29 mrnuke: you just need to make sure sht got real
19:30 imirkin_: meh. just use dirac notation.
19:30 imirkin_: no more dag's
19:31 mrnuke: is it a star, is it a dag, is it a ^-1, is it an asterix? I hated when that shit hit the chalkboard
19:31 imirkin_: hehe
19:32 mrnuke: I was working on my PhD. Hated it. Left that shit. Went into the military, came back and found a job as a hacker
19:32 imirkin_: wise move.
19:32 mrnuke: 'merican dream!
19:36 imirkin_: skeggsb: btw, perhaps the 16k thing should be for nvd9+ -- no idea
19:36 imirkin_: skeggsb: best i an do is 2x 1920x1200 screens which is nowhere close to those limits
22:55 mupuf: Nouveau-related talks at XDC: https://www.youtube.com/watch?v=dnG0X0uwLuY and https://www.youtube.com/watch?v=9J3BQcAeHpI